Выбор кластерного индекса с Django

Question

Я использую django с бэкэнд SQL Server.

Некоторые из моих столиков будут очень большими. Принимая обобщенный пример:

CREATE TABLE [dbo].[Data](
    [id] [int] NOT NULL, 
    [project_id] [int] NOT NULL, 
    [timestamp] [datetime] NOT NULL, 
    [value] [float]) 

[Data].[project_id] является внешним ключом к [Project].[id].

У меня будет индекс PK на [Task].[id], который также будет автоматически увеличиваться, в соответствии с практикой django.

У меня также будет уникальный индекс на [Data].[project_id],[Data].[timestamp], чтобы предотвратить дублирование данных.

Если большинство моих запросов будет искать по [Data].[project_id],[Data].[timestamp], лучше ли сделать этот индекс кластеризованным, или способ взаимодействия django с db означает, что кластеризация должна оставаться на первичном ключе?

Спасибо!

Answer 1

Если вы создали уникальный кластерный индекс PROJECT_ID, метки времени

• Большинство запросов будет выполнено с помощью кластерного индекса искать
• Там не будет, как представляется, необходимость некластеризованном индекса
• вы уже планируете индексирование это

Используя временную метку, project_id будет веским аргументом, если вы ищете на определенную дату, но большинство людей запрос для дат по диапазону. Это позволит вам искать диапазон дат, но затем придется сканировать эти данные, чтобы найти ваш project_id. SQL Server покажет это как поиск, с отметкой времени как «Искатель предикатов», а project_id - как «Предикат». Ваша цель состоит в том, чтобы как можно больше обращаться с помощью Predicate Seek.

Однако это трудно сказать, что это прекрасный ответ. Единственный способ узнать, правильно ли это, это установить его на место, подождать пару дней, а затем проверить dm_db_index_usage_stats, чтобы убедиться, что на самом деле большая часть использования этой таблицы на самом деле находится на project_id, timestamp. Если django использует их иначе, чем вы ожидаете, тогда может иметь смысл изменить это как просто ID.