Идентификатор строки индекса против строки DateTime

Question

У меня есть типичная таблица с целочисленным идентификатором первичного ключа и столбцом DateTime для записи при создании строки. Теоретически, порядок столбца Id должен всегда быть в том же порядке столбца DateTime. Мое приложение выполняет ORDER BY CreateDateTime DESC, и я собирался добавить индекс для столбца CreateDateTime, но затем я понял, что кластеризованный индекс на первичном ключе должен выполнить то же самое, и хотя он не является семантически правильным, может быть, я должен просто отсортировать по Id предотвратить создание другого индекса. Вы бы добавили индекс CreateDateTime в любом случае? А что, если бы это был столбец LastUpdatedDateTime (подразумевается случайное обновление индекса)?

Answer 1

Используйте Id.Это будет лучше учитывать изменения часового пояса

Answer 2

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

Это предполагает, что CreateDateTime всегда использует getdate () или сопоставим при вставке строки.Если вы ожидаете, что эта дата будет создана каким-то другим способом, я бы использовал индекс CreateDateTime и использовал бы его в предложении Order By.

Answer 3

"в теории" ... имеет ли значение, если практика не соответствует теории?

Если да, создайте индекс и упорядочите по этому полю даты. Если нет, используйте первичный ключ.

Answer 4

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

Будете ли вы выполнять множество запросов к таблице, специально основанной на столбце datetime?Если нет, то я не думаю, что вы выиграете от индекса там - придерживайтесь фактического идентификатора в качестве кластеризованного ключа.Тем более, если мы говорим о последнем обновленном столбце - какой процент ваших запросов будет использовать такой индекс?Не похоже, что это принесет вам много пользы (но это может стоить вам дорого в зависимости от частоты обновления данных).

Точно о каких сущностях идет речь?Эти пользователи, машины скорой помощи, куклы Барби, сообщения на форуме, вулканы, что-то еще?Сколько строк вы будете добавлять в день, неделю, месяц?Какие запросы вы выполняете против них?Представление об объеме и типах запросов может иметь большое значение при определении стратегий индекса.