Самый быстрый подход к схеме для этой таблицы?

Question

У меня есть следующая таблица в базе данных SQL Server 2008:

• ID UNIQUEIDENTIFIER NOT NULL
• Scope CHAR(5) NOT NULL
• Data NVARCHAR(MAX)

Таблица редко изменяется, но к ней часто обращаются, используя

SELECT Data 
WHERE ID = @X 
AND Scope = @Y

команда.

Data может быть любым от пустых до нескольких страниц текста. ID+Scope всегда будет уникальным. Таблица будет содержать несколько тысяч уникальных идентификаторов и менее 20 уникальных значений Scope.

Я пытаюсь убедиться, что использую лучшую стратегию для ключей / индексов. На данный момент я только что получил первичный некластеризованный ключ с использованием ID и Scope (в таком порядке).

Answer 1

Если предположить, что один только идентификатор не уникален, и что вы не склонны менять тип идентификатора на INT, то то, что вы сделали, является почти оптимальным.

• Вы используете nvarchar (max) вместо ntext - это будет работать лучше, и ntext запланирован как устаревший
• Ваш первичный ключ сортируется первым по наиболее селективному столбцу (ID)

Единственное, что я хотел бы добавить, это кластеризация вашего первичного ключа для повышения производительности. Это предпочтительнее, чем решение N West о добавлении кластеризованного индекса, потому что тогда у вас будет два дублированных индекса (PK и кластеризованный индекс), которые ухудшают производительность записи без увеличения производительности при чтении. Лучше просто кластеризовать индекс, который у вас уже есть: первичный ключ.

Отредактировано для добавления: Поскольку ваша таблица редко обновляется, использование поля ключа GUID не должно сбивать вас с толку почти так же, как в часто обновляемой таблице. Не идеально, но в вашей конкретной ситуации это должно оказать минимальное влияние.

Тем не менее, вы можете найти это раздражающим после того, как в первые несколько раз вам придется вручную вводить GUID, который кто-то нацарапал на Post-It, в окно запроса.

Answer 2

CREATE UNIQUE CLUSTERED INDEX ON <TableName> (ID, Scope)

Использование кластерного индекса ускорит ваши запросы, так как вы просто будете обходить дерево, чтобы получить каждый идентификатор / область.

Обратите внимание, что использование GUID будет медленным.Но это будет быстрее, чем кучи или некластеризованное сканирование ...