Целочисленное представление даты

Question

В последнем проекте у нас была проблема с производительностью нескольких запросов, которые сильно зависели от упорядочения результатов по полю даты и времени (база данных MSSQL 2008).

Когда мы выполняли запросы с помощью ORDER BY RecordDate DESC (или ASC), запросы выполнялись в 10 раз медленнее, чем без этого. Упорядочение по любому другому полю не дало таких медленных результатов.

Мы перепробовали все параметры индексации, использовали мастер настройки, ничего не изменилось.

Одним из предложенных решений было преобразование поля даты и времени в целочисленное поле, представляющее количество секунд или миллисекунд в этом поле даты и времени. Он будет рассчитан по простому алгоритму, что-то вроде «получите мне количество секунд от RecordDate до 1980-01-01». Это значение будет сохранено при вставке, и вся сортировка будет выполняться в целочисленном поле, а не в поле даты и времени.

Мы никогда не пробовали, но мне интересно, что вы, ребята, думаете?

Answer 1

Я считаю, что datetime физически хранится как float , поэтому улучшение будет таким же, как и при преобразовании float в INT.

Я бы предпочел использовать индексы, так как они предназначены для них, а время данных предназначено для хранения дат во времени. С датой и временем связан ряд функций, поэтому, если вы решите использовать пользовательский тип хранилища, вам придется позаботиться об этом самостоятельно.

Answer 2

Я не очень понимаю, почему индексация не помогает, если SQL за обложками хранит дату как целочисленное представление.

Сортировка по столбцам идентификаторов дает отличные результаты или по любому другому проиндексированному полю.

Answer 3

Единственный разумный способ хранения дат - юлианские дни - временные метки unix слишком коротки.

Под здравым смыслом я имею в виду действительно код - обычно (но не всегда) лучше хранить даты в базе данных как datetime.

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

Трудно быть конкретным, не видя подробной информации, такой как запросы, количество записей и т. Д., Но общий совет будет состоять в том, чтобы реструктурировать порядок и метод запроса, чтобы уменьшить количество заказываемых записей - как это сильно влияет на производительность.