Выбор кластерного индекса с 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 взаимодействует с БД, означает, что кластеризацию следует оставить на первичном ключе?

Спасибо!

Answer 1

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

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

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

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