Имеется таблица "Транзакции", в которой поля "ID карты" (CARD_ID INTEGER) и "время транзакции" (TRANTIME TIMESTAMP) входят в составной индекс, примерно так:



за период с 1.01.2017 по 9.08.2017 в таблице TRAN накоплено 367 тыс. транзакций по 11 тыс. картам, однако по карте с CARD_ID=100 всего лишь 2 транзакции.

Если я пишу запрос:




то он возвращает 2 транзакции, причем запрос выполняется в среднем 46 мс.
При этом IBExpert показывает:
Fetches from cache = 1 867


Если в запросе интервал времени небольшой (транзакции были 25 и 29 марта):



то запрос выполняется за 0 мс (редко 16 мс).
При этом IBExpert показывает:
Fetches from cache = 78

Разница - десятки раз!

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

Данная проблема снижения производительности свойственна только Firebird или это общая проблема, свойственная всем СУБД. В версиях Firebird 2.5 и 3.0 ситуация та же?

P.S. Версия Firebird 2.1.5 (SuperServer).

Симонов Денисты действительно считаешь 46 мс повод для беспокойства?


Потребовалось разработать EXECUTE BLOCK, который должен обработать все транзакции за указанный промежуток времени по каждой карте, а он работает жутко долго.

Симонов ДенисЧтобы лучше понять внутреннюю кухню читай http://www.ibase.ru/dataaccesspaths/

Знал, что дадут эту ссылку :)
На все случаи жизни.
Хорошо, попробую покопаться в этой статье.

dimitrоба плана используют TRAN_IDX1 и только его?


Фантастика!
Обнаружил, что у меня в SQL есть еще ORDER BY по полю TRANTIME.
Убрал его, запрос стал выполняться моментально.
По полю TRANTIME есть отдельный индекс :)

+0 в выражении сортировки отключит тебе индекс

Да, помогло!

Еще, как оказалось, при сортировке по полю DATA использовался составной индекс, включающий в себя 5 полей.

Что за привычка утаивать планы, телепатию нам прокачивать?

Сорри!

+1 тебе к телепатии :)