Если я избавляюсь от кластерных индексов на столбцах Guid

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

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

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

причина всего этого основана на понимании внутренней структуры индекса базы данных. Эти индексы называют сбалансированным деревом (B-дерево) индексы. они отчасти похожи на двоичное дерево, за исключением того, что каждый узел в дереве может иметь произвольное число записей, (и дочерние узлы), вместо всего два. То, что делает кластерный индекс отличающимся, - то, что вершины в кластерном индексе являются фактическими страницами данных физического диска самой таблицы. тогда как вершины некластерного индекса просто "указывают" на страницы данных таблиц.

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

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

Для некластерного индекса, это должно пересечь индекс однажды для каждой строки, которую это получает...

ПРИМЕЧАНИЕ: РЕДАКТИРОВАНИЕ
, Чтобы решить последовательную проблему для Столбцов ключа Гуида, знать, что SQL2k5 имеет NEWSEQUENTIALID (), который действительно на самом деле генерирует Гуиды "старый" последовательный путь.

или можно исследовать гуид РАСЧЕСКИ Jimmy Nielsens algotithm, который реализован в клиентском коде:

Гуиды РАСЧЕСКИ

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

Однако с основанными на целом числе кластерными индексами, целые числа обычно последовательны (как с IDENTITY спецификация), таким образом, они просто добавляются в конец, никакие данные не должны быть перемещены.

, С другой стороны, кластерные индексы находятся не всегда плохо на GUID... все это зависит от потребностей Вашего приложения. Если необходимо смочь к SELECT записи быстро, то используйте кластерный индекс... INSERT, скорость пострадает, но SELECT скорость будет улучшена.

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

Примечание, что при использовании SQL Server 2005, newsequentialid () , функция производит последовательный GUID. Это помогает предотвратить проблему фрагментации.

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

SELECT OBJECT_NAME (ips.[object_id]) AS 'Object Name',
       si.name AS 'Index Name',
       ROUND (ips.avg_fragmentation_in_percent, 2) AS 'Fragmentation',
       ips.page_count AS 'Pages',
       ROUND (ips.avg_page_space_used_in_percent, 2) AS 'Page Density'
FROM sys.dm_db_index_physical_stats 
     (DB_ID ('MyDatabase'), NULL, NULL, NULL, 'DETAILED') ips
CROSS APPLY sys.indexes si
WHERE si.object_id = ips.object_id
AND   si.index_id = ips.index_id
AND   ips.index_level = 0;

При использовании NewId (), Вы могли бы переключиться на NewSequentialId (). Это должно помочь перфекту вставки

Да, нет никакого смысла в наличии кластерного индекса на случайном значении.

Вы, вероятно, хотите кластерные индексы ГДЕ-НИБУДЬ в Вашей базе данных. Например, если у Вас есть таблица "Author" и таблица "Book" с внешним ключом "Автору", и если у Вас есть запрос в Вашем приложении, в котором говорится, "выберите... из Книги где AuthorId =..", затем Вы считали бы ряд книг. Это будет быстрее, если они закажут, физически друг рядом с другом на диске, так, чтобы головка диска не возвращалась вокруг от сектора до сектора, собирающего все книги того автора.

Так, необходимо думать о приложении, путях, которыми оно запрашивает базу данных.

Вносят изменения.

И затем тестируют, потому что Вы никогда не знаете...

Это зависит при выполнении большого количества вставок, или если Вам нужен очень быстрый поиск PK.

Да необходимо удалить кластерный индекс на первичных ключах GUID по причинам состояния Galwegian выше. Мы сделали это на наших приложениях.