Запрос агрегирует все строки по b, поэтому универсального ускорения по одной схеме таблицы нет. Нужно проверить реальный план: чтение данных, сортировку или hash aggregate, память и объём промежуточных данных.
Это план выполнения запроса
Запрос агрегирует все строки по b, поэтому универсального ускорения по одной схеме таблицы нет. Нужно проверить реальный план: чтение данных, сортировку или hash aggregate, память и объём промежуточных данных.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Условие
Это план выполнения запроса select b, sum(d) from T group by b к таблице create table T (A int not null primary key, b int, c int, d float). Внешних ключей таблица не имеет. Как сократить время выполнения запроса?
Ответ
Запрос агрегирует все строки по b, поэтому универсального ускорения по одной схеме таблицы нет. Нужно проверить реальный план: чтение данных, сортировку или hash aggregate, память и объём промежуточных данных.
В условии сам план не приложен. Возможные варианты для проверки: покрывающий индекс с ключом b и включённым d, обновление статистики, устранение сброса агрегации на диск, допустимый параллелизм. Индекс может сократить чтение лишних колонок или дать порядок по b, но не устраняет необходимость учесть все значения d.
Для частых запросов по большому неизменяемому набору полезна предварительная агрегация или materialized view с согласованным обновлением. Отсутствие внешних ключей само по себе не объясняет медленный GROUP BY. До и после сравнивают план и фактическое время на одинаковых данных.