Кандидат на некластеризованный индекс

У меня есть структура таблицы, как показано ниже:

Список функций

ID  - BIGINT - Primary Key  - Clustered Index
VIN - VARCHAR(50)
Text - VARCHAR(50)
Value - VARCHAR(50)

Большинство запросов, которые я выполняю, выглядят так:

SELECT * FROM FeatureList WHERE VIN = 'ABCD'    --- Will give multiple records

OR 

DELETE FROM FeatureList WHERE VIN = 'ABCD'

Я хочу знать, является ли столбец VIN хорошим кандидатом для некластеризованного индекса? Или это может ухудшить производительность?


sql performance sql-server-2008 indexing non-clustered-index
person Akon    schedule 14.11.2013    source источник
comment
Почему ПК БОЛЬШОЙ? Вы действительно собираетесь иметь более 2 миллиардов функций в этой таблице? В любом случае, не зная многого о вашей системе и о том, как дополнительные / более широкие индексы могут повлиять на вашу общую рабочую нагрузку, может иметь смысл сделать VIN кластеризованным. Тогда, по крайней мере, не потребуется поиск, чтобы получить другие столбцы в вашем запросе SELECT *...   -  person Aaron Bertrand    schedule 14.11.2013
comment
Левая фара, правая фара, переднее левое колесо, правое переднее колесо... Да, вы можете получить больше 2B функций на автомобиле.   -  person billinkc    schedule 14.11.2013
comment
Не на данном этапе .... в настоящее время я вижу, что он вырастет до ... от 5 до 10 миллионов записей ... Но есть ли вред в объявлении его как БОЛЬШОГО?   -  person Akon    schedule 14.11.2013
comment
@billinkc - Ты меня полностью понял :)   -  person Akon    schedule 14.11.2013
comment
BIGINT = 8 байт, INT = 4 байта - это дополнительные 4 байта на строку, плюс дополнительные 4 байта на строку в любом некластеризованном индексе. 10 миллионов строк * 4 байта * 1+? индексы = много потраченного впустую места на диске и, что более важно, в памяти.   -  person Aaron Bertrand    schedule 14.11.2013
comment
Не объявляйте VIN как varchar(50). Есть стандарты на эти вещи. VIN Предположим, что VIN США/Канада   -  person billinkc    schedule 14.11.2013
comment
@AaronBertrand - Да ... это имеет смысл ... но изменить их сейчас не представляется возможным с моей стороны ... Должен ли я сделать его некластеризованным индексом для повышения производительности?   -  person Akon    schedule 14.11.2013
comment
@billinkc - Кажется, я опоздал с реализацией этого.. Я обязательно буду помнить об этом.. в следующий раз, когда буду что-то разрабатывать.. Спасибо.   -  person Akon    schedule 14.11.2013
comment
@Akon, извини, у меня просто недостаточно информации, чтобы помочь тебе. Это как если бы я спросил тебя, стоит ли мне сменить машину на зимние шины, а ты даже не знаешь, где я живу. У вас действительно есть проблемы с производительностью? Или вы преждевременно оптимизируете?   -  person Aaron Bertrand    schedule 14.11.2013
comment
NCI имеет сомнительную ценность (учитывая AB или другие), поскольку даже если механизм ищет позицию, ему все равно придется выполнять поиск ключа, чтобы перейти к физическому индексу, чтобы получить остальные данные для выборки. Если бы у вас не было SELECT *, то, возможно, вам бы подошёл NCI.   -  person billinkc    schedule 14.11.2013
comment
@AaronBertrand - Но разве это не имеет смысла ... из двух типов запросов, которые я использую ... Какая именно информация здесь поможет?   -  person Akon    schedule 14.11.2013
comment
@billinkc - это смесь SELECT * и SELECT VIN,Text,Value - я понимаю вашу точку зрения.   -  person Akon    schedule 14.11.2013
comment
Да, у SQL Server есть теоретические планы, но ничего не гарантировано. Вы даже можете давать ему подсказки, и он может использовать или не использовать то, что вы говорите или ожидаете от него. Лучше всего проверить производительность ваших запросов с некластеризованным индексом и без него. Как уже говорили другие, выбранные вами поля могут оказать влияние. Например, индекс VIN, скорее всего, должен помочь, если вы делаете Select Vin From ..., но индекс может быть проигнорирован, если вы делаете Select Vin, Field2 from....   -  person ps2goat    schedule 14.11.2013
comment
В зависимости от сложности запросов (у вас они очень простые) вам могут потребоваться сотни тысяч или даже миллионы строк, прежде чем вы начнете замечать заметное влияние на производительность.   -  person ps2goat    schedule 14.11.2013
comment
У меня есть миллионы записей в этих таблицах из сценария миграции.   -  person Akon    schedule 14.11.2013

Ответы (1)


arrow_upward
0
arrow_downward

Необъявление индекса VIN абсолютно приведёт к резкому снижению производительности. Вы получаете небольшое снижение производительности при каждой вставке, удалении или обновлении с использованием VIN. Чтения (особенно когда вы попадаете в миллионы записей) будут выполняться на порядки быстрее.

Что касается BIGINT против INT, я обычно выбираю BIGINT. Да, он занимает немного больше места на диске. Да, он занимает немного больше памяти. Плюс для меня, тем не менее, заключается в том, что мне никогда не приходится беспокоиться о переносе таблицы (и любой другой таблицы, которая принимает идентификатор в качестве внешнего ключа) в BIGINT. Был там. Сделано это. Дополнительное пространство того стоит.

person MichaelMilom    schedule 14.11.2013
comment
Теперь в таблице есть миллионы записей.. В зависимости от запроса, который я разместил.. имеет ли смысл добавлять NCI в столбец VIN.. поскольку некоторые говорят об обратном.. - person Akon; 14.11.2013
comment
@Akon: это сильно зависит от сколько строк из ваших миллионов, которые вернет ваш запрос. Кроме того: использование SELECT * снижает вероятность использования индекса; лучше выбирать только столбцы, которые вам действительно нужны, а не все. Так что да - VIN определенно является кандидатом - вам нужно добавить индекс и измерить, действительно ли это помогает вашим запросам. - person marc_s; 14.11.2013
comment
SELECT * FROM FeatureList WHERE VIN = 'ABCD' это даст примерно от 5 до 10-15 записей. Не играет ли предложение WHERE роли в NCI - person Akon; 14.11.2013
comment
Я бы пошел по индексу. SELECT *, безусловно, повлияет на количество данных, возвращаемых запросом, но я не уверен, что согласен с тем, что это повлияет на использование индекса. Отсутствие предложения WHERE? Абсолютно. Я хотел бы увидеть статистику плана запроса, чтобы подтвердить это. - person MichaelMilom; 15.11.2013