Какой столбец кластерный индекс должен поставиться?
Это, что Вы ищете:
Используя ОБЪЕКТНЫЕ ПРЕДСТАВЛЕНИЯ КАТАЛОГА
SELECT T.name AS Table_Name ,
C.name AS Column_Name ,
P.name AS Data_Type ,
P.max_length AS Size ,
CAST(P.precision AS VARCHAR) + '/' + CAST(P.scale AS VARCHAR) AS Precision_Scale
FROM sys.objects AS T
JOIN sys.columns AS C ON T.object_id = C.object_id
JOIN sys.types AS P ON C.system_type_id = P.system_type_id
WHERE T.type_desc = 'USER_TABLE';
Используя ПРЕДСТАВЛЕНИЯ ИНФОРМАЦИОННОЙ СХЕМЫ
SELECT TABLE_SCHEMA ,
TABLE_NAME ,
COLUMN_NAME ,
ORDINAL_POSITION ,
COLUMN_DEFAULT ,
DATA_TYPE ,
CHARACTER_MAXIMUM_LENGTH ,
NUMERIC_PRECISION ,
NUMERIC_PRECISION_RADIX ,
NUMERIC_SCALE ,
DATETIME_PRECISION
FROM INFORMATION_SCHEMA.COLUMNS;
Ссылка: Мой Блог - http://dbalink.wordpress.com/2008/10/24/querying-the-object-catalog-and-information-schema-views/
5 ответов
Индекс, кластеризованный или некластеризованный, может использоваться оптимизатором запросов тогда и только тогда, когда крайний левый ключ в индексе фильтруется по. Итак, если вы определяете индекс для столбцов (A, B, C), условие WHERE на B = @ b , на C = @ c или на B = @ b AND C = @ c не будет полностью использовать индекс (см. примечание). Это также относится к условиям присоединения. Любой фильтр WHERE, включающий A , будет учитывать индекс: A = @ a или A = @ a AND B = @ b или A = @ а И С = @ c или A = @ a AND B = @ b AND C = @ c.
Итак, в вашем примере, если вы сделаете кластерный индекс на part_no как крайний левый ключ, то запрос, ищущий конкретный part_id , не будет использовать индекс и отдельный некластеризованный индекс должны существовать на part-id .
Теперь о вопросе, какой из многих индексов должен быть кластеризованным . Если у вас есть несколько шаблонов запросов, которые имеют примерно одинаковую важность и частоту и противоречат друг другу в терминах необходимых ключей (например, частые запросы по либо part_no , либо part_id ) тогда вы принимаете во внимание другие факторы:
- ширина : ключ кластеризованного индекса используется в качестве ключа поиска всеми другими некластеризованными индексами. Поэтому, если вы выберете широкий ключ (скажем, два столбца уникального идентификатора), вы сделаете все остальные индексы шире, тем самым потребляя больше места, генерируя больше операций ввода-вывода и все замедляя. Таким образом, между одинаково хорошими ключами с точки зрения чтения, выберите самый узкий как кластерный, а более широкий - некластеризованный.
- contention : если у вас есть определенные шаблоны вставки и удаления, попробуйте разделить их физически, чтобы они встречаются в разных частях кластерного индекса. Например. если таблица действует как очередь со всеми вставками на одном логическом конце и всеми удалениями на другом логическом конце, попробуйте разместить кластерный индекс так, чтобы физический порядок соответствовал этому логическому порядку (например, порядок постановки в очередь).
- разделение : если таблица очень большая и вы планируете развернуть партиционирование, то ключ разделения должен быть кластеризованным индексом. Типичный пример - исторические данные, которые заархивированы с использованием схемы разделения со скользящим окном. Даже если у сущностей есть логический первичный ключ, такой как 'entity_id', кластеризованный индекс выполняется столбцом datetime, который также используется для функции разделения.
- стабильность : ключ, который часто изменяется, является плохим кандидатом для кластеризованный ключ при каждом обновлении значения кластеризованного ключа и принудительное все некластеризованные индексы обновлять ключ поиска, который они хранят. Поскольку обновление кластеризованного ключа также, вероятно, переместит запись на другую страницу, это может вызвать фрагментацию кластерного индекса.
Примечание: не полностью , поскольку иногда механизм выбирает некластеризованный index to сканировать вместо кластерного индекса просто потому, что он уже и, следовательно, имеет меньше страниц для сканирования.B = @ b и проекты запросов C , индекс, вероятно, будет использоваться, но не как поиск, как сканирование, потому что он по-прежнему быстрее, чем полное кластерное сканирование (меньше страниц).
У Лутца Рёдера есть хороший порт с открытым исходным кодом Mapack. t принять во внимание при выборе) является тот факт, что ключ кластеризации (все столбцы, составляющие кластеризованный индекс) будет добавлен к каждой записи индекса для каждого некластеризованного индекса в вашей таблице - таким образом, «узкое» требование становится особенно важным!
Кроме того, поскольку ключ кластеризации используется для поиска по закладкам (поиск фактической строки данных, когда строка находится в некластеризованном индексе), «уникальное» требование также становится очень важным. важный. Фактически настолько важно, что если вы выберете (набор) столбцов, уникальность которых / не гарантируется, SQL Server добавит 4-байтовый идентификатор uniquefier к каждой строке ->, таким образом, делая каждый из ваших сверхширокие ключи кластерного индекса; определенно НЕ хорошо.
Марк
поскольку ключ кластеризации используется для поиска по закладкам (поиск фактической строки данных, когда строка находится в некластеризованном индексе), требование «уникальности» также становится очень важным. Фактически настолько важно, что если вы выберете (набор) столбцов, уникальность которых / не гарантируется, SQL Server добавит 4-байтовый идентификатор uniquefier к каждой строке ->, таким образом, делая каждый из ваших сверхширокие ключи кластерного индекса; определенно НЕ хорошо.Марк
поскольку ключ кластеризации используется для поиска по закладкам (поиск фактической строки данных, когда строка находится в некластеризованном индексе), требование «уникальности» также становится очень важным. Фактически настолько важно, что если вы выберете (набор) столбцов, уникальность которых / не гарантируется, SQL Server добавит 4-байтовый идентификатор uniquefier к каждой строке -> таким образом, делая каждый из ваших сверхширокие ключи кластерного индекса; определенно НЕ хорошо.Марк
Кластерные индексы удобны при запросе диапазонов данных. Например
SELECT * FROM theTable WHERE age BETWEEN 10 AND 20
Кластерный индекс упорядочивает строки на диске вашего компьютера в определенном порядке. Вот почему строки с возрастом = 10 будут рядом друг с другом, а после них будут строки с возрастом = 11 и т. Д.
Если у вас есть точный выбор, например:
SELECT * FROM theTable WHERE age = 20
некластеризованный индекс также хороший. Он не меняет порядок данных на диске вашего компьютера, но строит специальное дерево с указателями на нужные вам строки.
Таким образом, это сильно зависит от типа выполняемых вами запросов.
Помните о шаблонах использования; Если вы почти всегда запрашиваете базу данных по car_part_no, то, вероятно, было бы полезно кластеризовать ее по этому столбцу.
Однако не забывайте о соединениях; Если вы чаще всего присоединяетесь к таблице, и в этом соединении используется поле car_part_id, тогда у вас есть веская причина сохранить кластер на car_part_id.
Следует иметь в виду еще кое-что (в данном случае это не так, но обычно при рассмотрении кластеризованные индексы) заключается в том, что кластеризованный индекс неявно появляется в каждом другом индексе таблицы; Так, например, если вы индексируете car_part_title, этот индекс также будет неявно включать car_part_id. Это может повлиять на то, покрывает ли индекс запрос, а также влияет на то, сколько дискового пространства займет индекс (что влияет на использование памяти и т. Д.).
Кластерный индекс должен располагаться в столбце, который будет запрашиваться чаще всего. Это включает в себя соединения, так как соединение должно обращаться к таблице так же, как прямой запрос, и находить указанные строки.
Вы всегда можете перестроить свои индексы позже, если ваше приложение изменится и вы обнаружите, что вам нужно оптимизировать таблицу с другим структура индекса.
Некоторые дополнительные рекомендации по выбору кластеризации таблицы можно найти в MSDN здесь: Рекомендации по разработке кластеризованного индекса .