Об оптимизации запросов

Один сервер БД, чье название мне запретили произносить вслух, выполняет запрос select count(*) from events, просто читая таблицу целиком, что нормально. Количество прочитанных байт видно в статистике i/o.

Запрос select count(*), min(event_dt), event_src_id from events group by event_src_id выполняется, по той же статистике, судя по всему - методом "сначала создадим спискок значений event_src_id а затем для каждого id посчитаем min и count(*), т.к. оптимизатору так кажется эффективнее". При этом он у меня базу прочитал уже раз 10 по кругу, судя по статистике i/o.
По event_src_id есть индекс, и таки оно, похоже, в этот индекс усиленно долбится.
База мелкая, 12 гиг, табличка занимает из нее гиг 6 (без индексов), 66 млн записей.

Если принудительно указать оптимизатору план "прочитай таблицу целиком" - работает как надо, т.е. за время на чтение таблицы целиком.

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

PS: План запроса, выбранный оптимизатором: сортировка по индексу (event_src_id,event_dt).
Т.е. судя по всему, сначала чтение индекса(который сам по себе не мелкий), затем переход к странице данных (оне что, каждый раз ее перечитывают с диска, что ли) и затем обновление/подсчет агрегатов.

PPS: Ах ты ж блин.
Это же почти та же самая проблема, что была у dmzlj с postgresql - разреженное расположение данных при приходе их с кучи источников равномерно по времени в одну таблицу. Т.е. оно при сортировке по event_src_id читает для каждого значения event_src_id ВСЕ страницы данных - потому что на одной странице очень мало данных от одного источника - там данные за смежные интервалы времени от всех источников. Т.е. таблица будет прочитана по кругу количество раз примерно пропорциональное количеству источников данных.

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