Столкновения CHECKSUM() в SQL Server 2005

Question

У меня есть таблица из 5 651 744 строк с первичным ключом из 6 столбцов (int x 3, smallint, varchar (39), varchar (2)). Я хочу улучшить производительность с помощью этой таблицы и другой таблицы, которая разделяет этот первичный ключ плюс дополнительный добавленный столбец, но имеет 37-метровые строки.

В ожидании добавления столбца для создания хэш-ключа я сделал анализ и нашел 18,733 столкновений.

SELECT SUM(CT) 
FROM (
     SELECT HASH_KEY 
       ,COUNT(*) AS CT 
     FROM (
       SELECT CHECKSUM(DATA_DT_ID, BANK_NUM, COST_CTR_NUM, 
           GL_ACCT_NUM, ACCT_NUM, APPN_CD) AS HASH_KEY 
       FROM CUST_ACCT_PRFTBLT 
       ) AS X 
     GROUP BY HASH_KEY 
     HAVING COUNT(*) > 1 
     ) AS Y 

SELECT COUNT(*) 
FROM CUST_ACCT_PRFTBLT 

Это примерно в два раза хуже с BINARY_CHECKSUM()

ли это кажется слишком высокой (+0,33%), учитывая меньший относительный объем пространства назначения я покрывающей? И если коллизии настолько высоки, есть ли преимущество в объединении на этом изготовленном ключе сначала в соединениях для стоимости дополнительных 4 байтов в строке, учитывая, что вам все равно придется присоединяться к регулярным столбцам для обработки случайного столкновения?

Answer 1

Я не вижу, где добавление контрольной суммы получит вам что-нибудь с этим уровнем collisons. Даже 1 столкновение слишком велико, так как это приведет к тому, что вы присоединитесь к неправильным данным. Если вы не можете гарантировать, что присоединяетесь к правильной записи, бессмысленно, если оно улучшает производительность, но беспорядок с целостностью данных. Это, по-видимому, финансовые данные, поэтому вам лучше быть уверенным, что ваши запросы не приведут к плохим результатам. Фактически вы можете в конечном итоге списать или зачислить неправильные учетные записи, если есть какие-либо столкновения.

Если вы идете по этому маршруту, Marc прав, если вы планируете, если это возможно, если вы планируете все возможное (добавление вычислений, которое должно произойти с каждой записью в многомиллионных таблицах записей, вряд ли улучшит производительность в моем опыте). Возможно, если вы можете сделать предварительно вычисленный столбец (и вам понадобятся триггеры, чтобы поддерживать его актуальность), вам может не понадобиться присоединиться ко всем шестерке других столбцов, чтобы избежать столкновений. Тогда, возможно, у вас может быть высокая производительность. Все, что вы можете сделать, это проверить свою теорию. Но будьте уверены, что у вас нет коллизий.

Вы считали использование суррогатного ключа, а затем уникальным индексом на шести натуральных ключевых полях? Затем вы можете присоединиться к суррогатной клавише и, вероятно, улучшить производительность. Невозможно эффективно объединить шесть столбцов (один из варчаров) вместо одного суррогатного ключа. Я понимаю, по размеру данных, это может быть сложнее реорганизовать, чем в непроизводственной системе, но на самом деле, возможно, стоит потратить время на постоянное устранение постоянных проблем с производительностью. Только вы можете сказать, насколько сложным было бы это изменение и насколько сложно было бы изменить все sps или запросы для лучшего соединения. Тем не менее, можно попробовать.

Answer 2

Если ваша контрольная сумма упадет до 0,33% данных, я бы сказал, что он работает нормально ... особенно если вы используете этот столбец в сочетании с другими (проиндексированными) столбцами.

Конечно, чтобы быть эффективным как индекс, который вы, вероятно, хотите вычислить и сохранить это значение при вставке/обновлении данных, с некластеризованным индексом.

Конечно, регулярный охватывающий индекс по столбцам в вопросе может сделать так же хорошо или лучше ...

Answer 3

Если ваши запросы являются выборочными, а индекс кластеризации таблицы строк является узким или не существует, то некластеризованный индекс контрольной суммы в таблице строк должен обеспечивать хорошую производительность.

После применения любых критериев, присутствующих в таблице заголовков, он будет использовать контрольную сумму для выполнения поиска индекса в некластеризованном индексе. Вам все равно нужно включить FK в соединение, но критерии присоединения к неконтролируемой сумме будут применяться после индекса, поиск после закладок. Очень эффективный.

Вы хотите оптимизировать поиск индекса. Контрольная сумма уже очень избирательна. Добавление FK увеличило бы размер индекса и соответствующий ввод-вывод и не помогло бы, если бы он не включал достаточно других полей, чтобы избежать поиска по закладкам в целом.

Поскольку некластеризованный индекс будет содержать ключи кластеризации или указатель кучи, вы хотите: a) небольшой ключ кластеризации (например, столбец идентификатора int - 4 байтовый указатель) или b) не кластеризованный индекс вообще (8-байтовый указатель).

Если ваши запросы не являются выборочными, или если индекс кластеризации таблицы строк огромен (вся таблица минус несколько столбцов), то я не знаю, поможет ли контрольная сумма (возможно, более быстрая указательная навигация, возможно?). В любом случае вы хотели бы сделать его кластеризованным или охватывающим индексом, и если таблица заголовков сначала не кластеризуется в контрольной сумме, будет много сортировки.

Если вы можете позволить себе расходы на хранение и индексирование, возможно, будет несколько указателей на заголовок - заголовок и детализация.

Answer 4

Если ваш PRIMARY KEY сгруппирован, то каждый созданный вами индекс будет содержать это PRIMARY KEY.

Соединение на хеширован значение будет использовать эти следующие шаги:

1. Найдите значение хэш-индекса ключа
   • Найдите значение PRIMARY KEY в индексных данных
   • Использование Clustered Index Seek определить местонахождение PRIMARY KEY строка в таблице

Присоединение к PRIMARY KEY будет использовать только шаг 3.

SQL Server, однако, достаточно умен, чтобы принять это во внимание, и если вы присоединитесь, как это:

SELECT * 
FROM main_table mt 
JOIN CUST_ACCT_PRFTBLT cap 
ON  cap.HASH_KEY = mt.HASH_KEY 
     AND cap.DATA_DT_ID = mt.DATA_DT_ID 
     AND … 
WHERE mt.some_col = @filter_value 

, он просто не будет использовать индекс на HASH_KEY, вместо этого, он будет использовать один Clustered Index Seek и Filter, чтобы убедиться, что значения хэша совпадают (и они всегда будут).

Резюме: просто присоединитесь к PRIMARY KEY.

Используя вторичный индекс, вам сначала нужно будет сделать бесполезный поиск HASH_KEY, а затем еще нужно присоединиться к PRIMARY KEY.

Answer 5

То, что я видел много людей, замалчивающих до сих пор, состоит в том, что CHECKSUM имеет тонну столкновений, на Microsoft's own admission. Это даже хуже, чем MD5, что имеет свою долю значимых столкновений.

Если вы хотите получить хеш-столбец, рассмотрите использование HASHBYTES с указанным SHA1. SHA1 имеет гораздо менее значимые столкновения, чем MD5 или CHECKSUM. Поэтому CHECKSUM никогда не следует использовать, чтобы определить, является ли строка уникальной, а скорее, это быстрая проверка верности двух значений.Следовательно, ваша скорость столкновения должна быть 0% с HASHBYTES, если у вас нет повторяющихся строк (которые, будучи ПК, никогда не должны происходить).

Имейте в виду, что HASHBYTES усечет все, что превышает 8000 байт, но ваш ПК намного меньше этого (все конкатенированные), поэтому у вас не должно быть никаких проблем.