Назад к вопросам
Middle+
8
Дана таблица: create table bank_users ( id bigint generated by default as identity primary key, status int, employee_number varchar(8) unique, first_name varchar(100) not null, last_name varchar(100) not null, middle_name varchar(100) default null, email varchar(100) not null unique, created_at_date_time timestamptz ); create index ix_created_at_date_time_status on bank_users (created_at_date_time, status); Есть запрос: explain (costs off, verbose) select employee_number, first_name, last_name from bank_users where status = 2 order by created_at_date_time; Возвращает: Sort Output: employee_number, first_name, last_name, created_at_date_time Sort Key: bank_users.created_at_date_time -> Seq Scan on bank_users Output: employee_number, first_name, last_name, created_at_date_time Filter: (bank_users.status = 2) Что можно сказать об оптимальности плана запроса?
Компании, где спрашивали
Gravilink
Ответ от нейросети
sobes.tech AI
План запроса показывает, что используется последовательное сканирование (Seq Scan) таблицы bank_users с фильтром по status = 2, а затем сортировка по created_at_date_time.
Хотя есть индекс ix_created_at_date_time_status на (created_at_date_time, status), он не используется. Причина в порядке колонок в индексе и условиях запроса:
- Индекс построен по (created_at_date_time, status), то есть сначала сортировка по created_at_date_time, потом по status.
- В WHERE фильтруется по status, который во второй позиции индекса, что неэффективно для поиска.
Для оптимизации стоит создать индекс, где status будет первым столбцом, например:
CREATE INDEX ix_status_created_at ON bank_users (status, created_at_date_time);
Тогда планировщик сможет использовать индекс для быстрого поиска по status и сразу получить данные в отсортированном по created_at_date_time порядке, что позволит избежать сортировки и Seq Scan.
Итог: текущий план не оптимален, можно улучшить индекс для ускорения запроса.