1 джойна, проблема сохраняется
Две таблицы:
order (хранятся заказы, статус и прочие подробности), индексы pk_order_id, ix_order_status (по столбцу status) и другие
order_customer(распределение заказов по клиентам, два столбца: order_id, customer_id), индексы , ix_order_customer_id по столбцу customer_id
[про то, что можно закинуть customer_id в таблицу order знаю, в моем случае это нужно для других целей, в подробности вдаваться не буду, так как запрос упрощен]
Запрос считает кол-во заказов для конкретного юзера согласно распределению в таблице order_customer при условии, что статус не (6,7,8,17)
Сейчас в плане запроса Hash Match и Index Seek по ix_order_status, то есть ищем все заказы с нужным статусом, но без привязки к id заказа, что есть долго
Если после FROM добавить хинт with(index(pk_order_id)), то получаю оптимальный план и быстрое выполнение
Почему оптимизатор тригерится на предикат status not in (...)? Можно ли решить проблему без with(index())?
с хинтом Estimated Subtree Cost = 276, без него 44 дело скорее всего в статистике?
Не думаю. В плане с хинтом Nested Loops?
Обсуждают сегодня