Если ваш ключ - это GUID, то некластеризованный индекс на нем, вероятно, так же эффективен, как и кластеризованный индекс на нем. Это потому, что на GUID вы никогда не сможете сканировать диапазон (что может означать between 'b4e8e994-c315-49c5-bbc1-f0e1b000ad7c' and '3cd22676-dffe-4152-9aef-54a6a18d32ac' ??). При ширине 16 байт ключ кластеризованного индекса GUID шире, чем идентификатор строки, который вы получили бы из кучи, поэтому NC-индекс в руководстве PK на самом деле является стратегией, которую можно защитить в ходе обсуждения.
Но превращение первичного ключа в ключ кластеризованного индекса - не единственный способ построить кластеризованный индекс в куче. У вас есть другие частые запросы, в которых запрашиваются диапазоны по определенному столбцу? Типичными кандидатами являются такие столбцы, как date, state или deleted. Если вы это сделаете, вам следует подумать о том, чтобы сделать эти столбцы ключом кластеризованного индекса (он не должен быть уникальным), потому что это может помочь запросам, которые запрашивают диапазоны, например «все записи за вчерашний день».
Единственный сценарий, в котором кучи имеют значительное преимущество в производительности, - это вставки, особенно массовые вставки. ЕСЛИ ваша нагрузка невелика, вам определенно следует использовать кластерный индекс. См. Рекомендации по созданию кластерного индекса.
Переходя к вашим точкам:
Почти наверняка захочется установить кластерный индекс для каждой таблицы в вашей базе данных. Если в таблице его нет. Производительность наиболее распространенных запросов лучше.
Кластеризованный индекс, который может удовлетворять требованиям диапазона для большинства запросов, действительно значительно повысит производительность. Кластеризованный индекс, который может удовлетворять требованиям к порядку, тоже может быть полезен, но нигде так не полезен, как индекс, который может удовлетворять диапазону.
Кластерные индексы не всегда плохо работают с идентификаторами GUID ... все зависит от потребностей вашего приложения. Скорость INSERT пострадает, но скорость SELECT будет улучшена.
Будут улучшены только ВЫБОРЫ датчиков: SELECT ... WHERE key='someguid';. Запросы по идентификатору объекта и поиск по внешнему ключу выиграют от этого кластерного индекса. Индекс NC также может служить той же цели.
Проблема с кластеризованными индексами в поле GUID заключается в том, что идентификаторы GUID являются случайными, поэтому при вставке новой записи значительную часть данных на диске необходимо переместить, чтобы вставить записи в середину таблицы.
Неправильный. Вставка в позицию в индексе не должна перемещать данные. Худшее, что может случиться, - это разделение страницы. Разделение страниц (почему-то) дорого, но это не конец света. Ваш комментарий предполагает, что нужно переместить все данные (или, по крайней мере, «значительную» часть), чтобы освободить место для новой строки, это далеко не так.
Кластерный индекс по GUID подходит в ситуациях, когда GUID имеет значение и повышает производительность за счет размещения связанных данных близко друг к другу http://randommadness.blogspot.com/2008/07/guids-and-clustered-indexes.html
Я не могу представить себе сценарий, в котором GUID может иметь «связанные данные». GUID - это типичная случайная структура, как два случайных идентификатора GUID могут быть связаны любым образом? Сценарий Дональда имеет лучшее решение: Устранение разногласий PAGELATCH для высоконагруженных рабочих нагрузок INSERT, что дешевле в реализации (требуется меньше места для хранения) и работает также для уникальных ключей (решение в связанной статье не будет работать для уникальных ключи, только для внешних ключей).
Кластеризация не влияет на скорость поиска - уникальный некластеризованный индекс должен выполнять свою работу.
Для зондов (поиск определенного уникального ключа) да. NC-индекс почти работает так же быстро, как кластеризованный индекс (поиск NC-индекса требует и дополнительного поиска ключа для выборки в остальных столбцах). Лучше всего кластеризованный индекс показывает сканирование диапазона, поскольку кластерный индекс может покрыть любой запрос, а индекс NC, который может потенциально удовлетворять тому же диапазону, может потерять покрытие и запускает критический момент для индекса .
person
Remus Rusanu
schedule
13.12.2010
