Каков наилучший способ хранения DateTime в SQL Server, чтобы обеспечить максимальную скорость поиска на большой таблице?

Question

Каков наилучший способ хранения DateTime в SQL Server, чтобы обеспечить максимальную скорость поиска для большой таблицы?Таблица содержит записи, и одна строка должна содержать дату и время.

Поиски похожи на

Value > '2008-1-1' AND Value < '2009-1-1'

или

Value > '2008-1-1' AND Value < '2008-31-1'

и т. Д.

Что лучше?DateTime с индексом?Unixstamp в long с индексом?Несколько int полей, таких как год, месяц, день и т. Д.Или что-то другое?

Answer 1

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

• datetime2, если вам нужна высокая точность до 100 наносекунд (6-8 байт) (SQL 2008 +)
• datetime для точности до 3,33 мс (8 байт)
• smalldatetime для точности до минуты (4 байта)
• дата для точности до дня (время не сохраняется, 3 байта) (SQL 2008 +)

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

Answer 2

Ваш пример показывает только элемент даты и времени.Если вам нужна только дата, используйте относительно новый тип DATE вместо DATETIME.Он меньше и с индексом должен быть быстрым.

Answer 3

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

Конечно, введение индексов может повысить производительность.Индексы должны включать как можно меньше столбцов, чтобы хранить максимальное количество записей на одной странице.

Но ...

Преждевременная оптимизация является корнем всего зла

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