Индексы и производительность

Представьте составной B-деревянный индекс по полям «клиент» и «дата». Почему запрос, фильтрующий только по дате, может почти не получить от него пользы?

После массовой загрузки данных прежний запрос резко замедлился, хотя индексы не менялись. Какой механизм статистики мог привести к выбору неудачного плана?

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

В продакшене один параметризованный запрос быстро обрабатывает редких клиентов, но резко замедляется для клиента с большим объёмом данных; после очистки кэша результат меняется. Какой механизм объясняет такую нестабильность?

За счёт чего покрывающий индекс может ускорить запрос, даже если условие фильтрации возвращает те же строки?

Сравните, при каких условиях оптимизатор выбирает полное сканирование таблицы вместо индексного поиска, даже когда подходящий индекс существует?

Разберите ситуацию: запрос возвращает немного строк, но сортировка результата занимает заметное время. Как индекс может устранить отдельную операцию сортировки?

Что происходит с производительностью массовых вставок, когда у таблицы много вторичных индексов?

План показывает индексный поиск, но запрос всё равно работает медленно при большом числе найденных строк. Какой механизм может сделать такой план невыгодным?

В таблице два фильтруемых столбца сильно коррелируют, статистика по каждому свежая, но план систематически недооценивает число строк. Какой механизм приводит к такой ошибке оценки?

В таблице с кластеризованным B-деревом случайные вставки постепенно замедлили диапазонное чтение при неизменном числе строк. Какой механизм индекса это объясняет?

В SQL Server запрос к индексируемому столбцу неожиданно получает план со сканированием. Объясните механизм на примере несовпадения типов параметра и столбца:

CREATE TABLE dbo.Clients (
    ClientCode varchar(20) NOT NULL,
    Name       varchar(100) NOT NULL
);

CREATE INDEX IX_Clients_ClientCode
    ON dbo.Clients (ClientCode);

DECLARE @code nvarchar(20) = N'ABC123';

SELECT Name
FROM dbo.Clients
WHERE ClientCode = @code;

На таблице есть отдельные индексы по двум столбцам фильтрации, но оптимизатор использует только один из них. Объясните, почему он может не выполнять пересечение результатов этих индексов.

Запрос с неизменным планом заметно быстрее при повторном запуске. Какой механизм объясняет разницу?

В поиске по индексируемому текстовому полю условие с известным началом быстро, а поиск по произвольному фрагменту заметно медленнее. Объясните причину.

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

В PostgreSQL план показывает индексное сканирование только по индексу, но запрос всё равно читает таблицу. Какой механизм MVCC это объясняет?

В плане появляется bitmap-сканирование вместо обычного индексного поиска. Какой компромисс оптимизатор пытается выиграть?

В плане запроса одно условие указано как Seek Predicate, а другое — как Predicate. Какое практическое последствие имеет такое разделение?

В PostgreSQL нужно быстро получать первые 20 оплаченных заказов. План выбирает индекс по дате, хотя условие по статусу отбрасывает большинство строк. Объясните механизм, из-за которого LIMIT может сделать такой план предпочтительным.

CREATE TABLE orders (
    id         bigint PRIMARY KEY,
    status     text NOT NULL,
    created_at timestamp NOT NULL
);

CREATE INDEX ix_orders_created_at ON orders (created_at DESC);
CREATE INDEX ix_orders_status ON orders (status);

EXPLAIN
SELECT id, created_at
FROM orders
WHERE status = 'paid'
ORDER BY created_at DESC
LIMIT 20;