Sql Server: уникальный идентификатор плюс целочисленное соединение ПК ... какой тип индекса использовать?

Question

В моей базе данных SQL Server 2005 есть таблица соединений, состоящая из двух столбцов:

• object_id (уникальный идентификатор)

• property_id (целое число)

Эти значения вместе составляют составной первичный ключ.

Как лучше всего создать этот индекс PK для производительности SELECT?

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

Кто-нибудь имеет опыт в этой ситуации?

Answer 1

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

См. Блог Кима Триппа - в частности, " Дебаты CLustered Index продолжаются " и " GUID как PRIMARY и / или CLUSTERED key " - для получения много полезной информации.

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

Марк

Answer 2

Одной из альтернатив является использование так называемого суррогатного ключа (который также может быть назначен в качестве первичного ключа).

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

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

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

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

Определение суррогатного ключа: http://en.wikipedia.org/wiki/Surrogate_key

Answer 3

Я бы создал столбец идентификаторов, а затем сделал бы его вашим первичным ключом и кластерным индексом. Затем вы можете создавать некластеризованные индексы в objectid propertyid по мере необходимости.

Вы можете создать уникальное ограничение для обеспечения уникальности вашего ключа.

Причина этого в том, что строки будут вставляться последовательно, поэтому ваша сокращающая страница разбивается. кроме того, использование целого числа для вашего PK означает, что у вас есть меньшее значение для вашего кластеризованного индекса.