Индексация производительности BigInt по сравнению с VarChar

Мне нравится предшествование запятой путь:

SELECT
      column1
    , column2
    , column3
    , COALESCE(column4,'foo') column4
FROM
    tablename
WHERE
    column1 = 'bar'
ORDER BY 
      column1
    , column2

это делает это самым легким, чтобы считать и отладить, по-моему.

7
задан Raj More 21 October 2009 в 21:27
поделиться

3 ответа

Вы должны ОБЯЗАТЕЛЬНО ввести суррогат INT IDENTITY () первичный ключ !! INT уже потенциально дает вам до 2 миллиардов строк - разве этого не достаточно ??

Этот первичный ключ / кластерный ключ на SQL Server будет иметь размер до 64 байтов (вместо 4 для INT), что сделает ваш кластерный индекс И весь ваш некластеризованный индекс раздутым до неузнаваемости. Весь ключ кластеризации (все ваши 8 столбцов) будет включен на каждую страницу каждого отдельного некластеризованного индекса в этой таблице, что наверняка будет занимать много и много места.

Таким образом, в любой данной таблице индексов у вас будет до 16 раз больше записей с суррогатным кластеризованным ключом INT - это означает намного меньше операций ввода-вывода, намного меньше времени, потраченного впустую на чтение страниц индекса.

И только представьте, что вы пытаетесь установить связь по внешнему ключу с этой таблицей ... любая дочерняя таблица должна иметь все 8 столбцов вашего первичного ключа в качестве столбцов внешнего ключа, и укажите все 8 столбцов в каждом соединении - какой кошмар !!

При 78 миллионах строк даже простое изменение ключа кластеризации на INT IDENTITY сэкономит вам до 60 байтов на строку - одного этого хватило бы 4 ГБ дискового пространства (и использование ОЗУ на вашем сервере). И это даже не начало подсчета экономии на некластеризованных индексах .......

И, конечно же, да, я бы также изменил VARCHAR (10) на INT или BIGINT - если это число, сделайте тип поля числовым - на самом деле нет смысла оставлять его в VARCHAR (10). Но одно это не имеет большого значения с точки зрения скорости или производительности - это просто значительно упрощает работу с данными (не нужно всегда переходить к числовым типам, например, при сравнении значений и т. Д.)

Марк

При 78 миллионах строк даже простое изменение ключа кластеризации на INT IDENTITY сэкономит вам до 60 байт на строку - только это даст до 4 ГБ дискового пространства (и использования ОЗУ на вашем сервере). И это даже не начало подсчета экономии на некластеризованных индексах .......

И, конечно же, да, я бы также изменил VARCHAR (10) на INT или BIGINT - если это число, сделайте тип поля числовым - на самом деле нет смысла оставлять его в VARCHAR (10). Но одно это не имеет большого значения с точки зрения скорости или производительности - это просто значительно упрощает работу с данными (не нужно всегда переходить к числовым типам, например, при сравнении значений и так далее).

Марк

При 78 миллионах строк даже простое изменение ключа кластеризации на INT IDENTITY сэкономит вам до 60 байт на строку - только это даст до 4 ГБ дискового пространства (и использования ОЗУ на вашем сервере). И это даже не начало расчета экономии на некластеризованных индексах .......

И, конечно же, да, я бы также изменил VARCHAR (10) на INT или BIGINT - если это число, сделайте тип поля числовым - на самом деле нет смысла оставлять его в VARCHAR (10). Но одно это не имеет большого значения с точки зрения скорости или производительности - это просто значительно упрощает работу с данными (не нужно всегда переходить к числовым типам, например, при сравнении значений и т. Д.)

Марк

даже простое изменение ключа кластеризации на INT IDENTITY сэкономит вам до 60 байтов на строку - только это даст до 4 ГБ дискового пространства (и использования ОЗУ на вашем сервере). И это даже не начало подсчета экономии на некластеризованных индексах .......

И, конечно же, да, я бы также изменил VARCHAR (10) на INT или BIGINT - если это число, сделайте тип поля числовым - на самом деле нет смысла оставлять его в VARCHAR (10). Но одно это не имеет большого значения с точки зрения скорости или производительности - это просто значительно упрощает работу с данными (не нужно всегда переходить к числовым типам, например, при сравнении значений и так далее).

Марк

даже простое изменение ключа кластеризации на INT IDENTITY сэкономит вам до 60 байтов на строку - только это даст до 4 ГБ дискового пространства (и использования ОЗУ на вашем сервере). И это даже не начало расчета экономии на некластеризованных индексах .......

И, конечно же, да, я бы также изменил VARCHAR (10) на INT или BIGINT - если это число, сделайте тип поля числовым - на самом деле нет смысла оставлять его в VARCHAR (10). Но одно это не имеет большого значения с точки зрения скорости или производительности - это просто значительно упрощает работу с данными (не нужно всегда переходить к числовым типам, например, при сравнении значений и т. Д.)

Марк

s даже не начал подсчитывать экономию на некластеризованных индексах .......

И, конечно же, да, я бы также изменил VARCHAR (10) на INT или BIGINT - если это число, сделайте тип поля числовой - на самом деле нет смысла оставлять его в VARCHAR (10). Но одно это не имеет большого значения с точки зрения скорости или производительности - это просто значительно упрощает работу с данными (не нужно всегда переходить к числовым типам, например, при сравнении значений и так далее).

Марк

s даже не начал подсчитывать экономию на некластеризованных индексах .......

И, конечно же, да, я бы также изменил VARCHAR (10) на INT или BIGINT - если это число, сделайте тип поля числовой - на самом деле нет смысла оставлять его в VARCHAR (10). Но одно это не имеет большого значения с точки зрения скорости или производительности - это просто значительно упрощает работу с данными (не нужно всегда переходить к числовым типам, например, при сравнении значений и так далее).

Марк

14
ответ дан 6 December 2019 в 10:01
поделиться

Две вещи, которые могут повлиять на производительность индекса (и общей БД):

1) Размер страницы индекса 2) Скорость сравнения

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

BigInt составляет 8 байтов; VARCHAR может быть меньше, если размер данных небольшой, поэтому это действительно зависит от ваших данных. Однако числа длиной 10 символов могут соответствовать типу данных SQL Server INT ( http://msdn.microsoft.com/en-us/library/ms187745.aspx ) в зависимости от размера, поэтому int vs. bigint зависит от вашего домена.

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

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

Наконец, Марк прав в том, что это становится очень запутанным первичным ключом. Однако, если ваши данные этого требуют - например, это ваши ЕДИНСТВЕННЫЕ столбцы, и вы никогда не выполняете дополнительных запросов - вы можете прекрасно сделать оптимизированную версию (с Bigints и т. Д.) Своим первичным ключом. Тем не менее, это своего рода запах кода, поэтому я повторю его совет по-настоящему взглянуть на вашу модель данных и убедиться, что это правильно.

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

Наконец, Марк прав в том, что это становится очень запутанным первичным ключом. Однако, если ваши данные этого требуют - например, это ваши ЕДИНСТВЕННЫЕ столбцы, и вы никогда не выполняете дополнительных запросов - вы можете прекрасно сделать оптимизированную версию (с Bigints и т. Д.) Своим первичным ключом. Тем не менее, это своего рода запах кода, поэтому я повторю его совет по-настоящему взглянуть на вашу модель данных и убедиться, что это правильно.

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

Наконец, Марк прав в том, что это становится очень запутанным первичным ключом. Однако, если ваши данные этого требуют - например, это ваши ЕДИНСТВЕННЫЕ столбцы, и вы никогда не выполняете дополнительных запросов - вы можете прекрасно сделать оптимизированную версию (с Bigints и т. Д.) Своим первичным ключом. Тем не менее, это своего рода запах кода, поэтому я повторю его совет по-настоящему взглянуть на вашу модель данных и убедиться, что это правильно.

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

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

4
ответ дан 6 December 2019 в 10:01
поделиться

Марк С. прав в том, что 64-байтовый первичный ключ будет дублироваться в каждый индекс NC, поэтому вы собираетесь заплатить стоимость ввода-вывода, которая повлияет на объем данных который хранится в памяти (поскольку вы тратите место на странице индекса ЧПУ). Итак, исходя из этого, вопрос не в том, нужно ли мне преобразовать свои varchars, а в том, стоит ли мне подумать о преобразовании моего кластерного индекса во что-то совершенно другое. /

С точки зрения varchar и bigint есть веская причина для преобразования, если вы может позволить себе время; то есть за пределами двухбайтовой разницы в хранении на поле, при сравнении значений двух разных типов SQL будет вынужден преобразовать одно из них. Это будет происходить при каждом сравнении, будь то индексное соединение или предикат в предложении where.

1
ответ дан 6 December 2019 в 10:01
поделиться
Другие вопросы по тегам:

Похожие вопросы: