Где следует поместить индексы в таблицу измерения времени?

После прочтения Вопросов и Ответов с этого сайта об индексах у меня возник вопрос.

Что делать, если использовать таблицу измерения времени с более низким уровнем детализации, являющимся днем. Куда нужно ставить индексы?

Рэнди Мелдер в вопросе: что означает «индекс» в РСУБД? сказал :

Думайте об индексе как о «оглавлении» ... это упорядоченный список указателей на позиции в файле, то есть смещения

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

Мой вопрос: нужно ли ставить индексы для всех этих полей?

Предполагается, что день уникален, поэтому я прекрасно понимаю использование индексов. Но идентификатор недели будет иметь 7 событий , идентификатор месяца будет иметь 30/31 событий , идентификатор квартала будет иметь более или менее 120 событий .

• Стоит ли ставить индексы для этих полей?
• Это все еще будет полезно?

Я спрашиваю вас об этом, потому что в том же вопросе Дэвид Спиллетт сказал:

Конечно, добавление слишком большого количества индексов может быть плохой оптимизацией, поскольку дополнительное пространство, используемое для хранения индексов (и нагрузка ввода-вывода для их поддержания, если ваша БД видит много операций записи), может быть более серьезной проблемой, чем чуть менее оптимальные запросы чтения. так что не переусердствуйте.

Итак, каковы наилучшие соображения для случая измерения времени?

Скорее всего, вы не столкнетесь с проблемами записи, поскольку я предполагаю, что это будет что-то созданное один раз (или один раз в год), а затем не затронутое.

Но использование индекса, скорее всего, будет помехой, если вы будете искать по неделям ... Проблема в том, что, если индекс используется, он может сначала отсканировать это, а затем извлечь каждую запись из таблицы по отдельности, что, когда вы ' Если вы извлекаете более 5-20% записей, обычно быстрее выполнить полное сканирование таблицы, а затем отбросить записи, которые вам не нужны.

Я не знаю ни одной крупной СУБД, которая бы не оптимизировала это для хорошо распределенных данных. Если оно не распределено должным образом (например, одно из значений в столбце встречается в 95% случаев, но есть и другие возможные значения), вам, возможно, придется вычислять гистограммы в таблице и не использовать заполнитель для значения при поиске, так что оптимизатор запросов будет иметь значение, которое ищется при создании плана выполнения.

Я бы, вероятно, не указывал день недели. Я бы проверил документацию моей базы данных, чтобы увидеть, каков их компромисс между индексированными чтениями и полным просмотром таблиц, чтобы узнать, проиндексировал ли бы я день месяца или месяца года. Скорее всего, я бы указывал DOY / день года, если он присутствует (в любом случае это ваш уникальный индекс)

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

Общее правило состоит в том, что чем более избирателен индекс (селективность определяется как количество уникальных значений в столбце, деленное на количество строк в таблице), тем более вероятно, что механизм будет использовать индекс, если запрос использует столбец в предложении where.

Если вы рассматриваете возможность индексации столбца, выполнение запроса, выбирающего индексированный столбец до и после и просмотр планов выполнения, покажет вам, используется ли индекс, и если да, то насколько этот индекс помогает. В идеале, запрос, который вы используете для теста, будет использоваться вашим приложением.

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

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