iBase.ru Forum

Прочитал Хелен Борри про Firebird, но так и не
нашел ответа на свой вопрос.
Посему решил обратится к разработчикам, да и просто опытным пользователям FireBird.

Имеется табличка ~9 млн записей, из которых требуется постоянно выбирать 8-9тыс записей имеющих флажок (поле со значением 0), отсортированные по дате. Т.е. запрос вида:
SELECT FIELD1, FIELD2
FROM TABLE1
WHERE FIELD3 = 0
ORDER BY FIELD_DATE;

В связи с тем, что создавать индекс на часто повторяющихся полях не советуют, а в том поле всего два значения 0 и 1, то создавать индекс пока не хочу. С другой стороны, думаю над созданием составного индекса FIELD_DATE, FIELD3.

Естественно, прочитал в книге о том, что при использовании условия отбора по FIELD3 в данном случае индекс использоваться не будет, но при той же сортировке по FIELD_DATE этот индекс использоваться будет.

Теперь вопрос: будет ли использоваться этот индекс в моем запросе
SELECT FIELD1, FIELD2
FROM TABLE1
WHERE FIELD3 = 0
ORDER BY FIELD_DATE;
для а) отбора записей? б) сортировки записей? в) и то, и другое

Может предложите свой вариант увеличения производительности данного запроса?

Зависит ещё и от зависимости между "офлажкованными" записями и датами, которые они имеют.
Я думаю, что быстрее всего всё же будет выбираться по индексу по полю FIELD3. Хоть в других случаях он и не рекомендуется, но у тебя только 1/1000 всех значений имеют флажок, так что его (индекса) применение себя оправдает.
Составной индекс по дате + флажок или отдельно только по дате будет тормозить не по-детски, потому что листать будет по индексу с начала, долго.

ЗЫ: Чем писать в конфу, можно было достаточно быстро опробовать все возможные варианты на тестовой таблице с тестовыми записями.

WildSery писал(а):Зависит ещё и от зависимости между "офлажкованными" записями и датами, которые они имеют.

Зависимости никакой нет, на каждую дату приходится ~2000 записей.

WildSery писал(а): Я думаю, что быстрее всего всё же будет выбираться по индексу по полю FIELD3. Хоть в других случаях он и не рекомендуется, но у тебя только 1/1000 всех значений имеют флажок, так что его (индекса) применение себя оправдает.

Я склонялся к этой идее, но не решался на ее осуществление.

WildSery писал(а): Составной индекс по дате + флажок или отдельно только по дате будет тормозить не по-детски, потому что листать будет по индексу с начала, долго.

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

Композит с датой спереду тут ни в борозду ни в красную армию. Индекс по флажку будет весьма полезен в запросах на равенство 0 (если там действительно их 1/1000 от общего количества) и уложит сервак на пол при услвии в запросе на равенство единице. То есть, в таких запросах придётся не забывать всегда глушить его хинтом. Ещё этот индекс увеличит время рестора базы, сборки мусора в этой таблице и свипа. Чтобы снять этот вред, можно сделать индекс не по голому флажку, а композит (флажок, чтонить сильно уникальное например ID). Тогда индекс станет уникальным или почти, но будет работать по условию на флажок как индекс по голому флажку со всеми плюсами и минусами. Тут зарыта дополнительная грабля - оптимизатор будет верить, что индекс очень хороший и станет подхватывать его в сложных запросах с условием в том числе на флажок, игнорируя другие, полезные для них индексы, и переиначивая порядок соединения таблиц, там где на индекс по голому флажку не обратил бы внимания. То есть, там его тоже придётся глушить. Садимся, чешем репу, выбираем из трёх зол наиболее приемлемое.