Работая в sqlite v3, у меня есть запрос, который нуждается в календарной таблице, по сути, для расширения ежемесячных счетов в ежедневные счета. Несмотря на тщательное добавление индексов (и использование EXPLAIN QUERY PLAN), он все еще слишком медленный для моих нужд.
Вопрос по сути:
SELECT stuff
FROM (<subquery>) AS calendar
INNER JOIN ...
INNER JOIN ...
INNER JOIN ...
GROUP BY calendar.date
, где < подзапрос > - отличный трюк для создания календаря, который я где-то подобрал:
SELECT DATE('#{start_time.to_s(:db)}', (d4.digit * 10000 + d3.digit * 1000 + d2.digit * 100 + d1.digit * 10 + d0.digit) || ' DAYS') AS date
FROM digits AS d0
INNER JOIN digits AS d1
INNER JOIN digits AS d2
INNER JOIN digits AS d3
INNER JOIN digits AS d4
WHERE (d4.digit * 10000 + d3.digit * 1000 + d2.digit * 100 + d1.digit * 10 + d0.digit) < #{ndays}
ORDER BY date
(Да, таблица цифр предварительно загружена цифрами 0 ... 9. Как это действительно работает, оставлено читателю в качестве упражнения!)
Я знаю, что календарный подзапрос быстрый (<50 мс). Но после перечитывания документации sqlite я понимаю, что GROUP BY calendar.date во внешнем запросе вынуждает генерировать индекс на calendar.date. Поскольку календарь генерируется динамически, он не индексируется. </p>
Итак, вопрос, всегда с вопросами:
- Может ли отсутствие индекса в calendar.date быть источником снижения производительности? (Как я уже говорил, я был осторожен при индексации таблиц, используемых во внешнем запросе.)
- Буду ли я счастлив, просто создав гигантский 20-летний стол и проиндексировав его? Или есть лучший способ?
- Я был довольно хорош в том, чтобы заставить MySQL работать хорошо. Есть ли какие-нибудь приемы оптимизации (или ошибки), которые я должен знать?
ТИА ...