Если вы хотите настроить запрос, вы должны понимать свою модель данных и свои данные.Оптимизатор говорит, что не может эффективно использовать индекс для TRX_T
.Давайте посмотрим на этот составной индекс:
CODE
: используется в критериях объединения SUBID
: используется в критериях соединения TYPE
: не используется STATUS
: можно использовать в качестве фильтра? NO_SL
: не используется
В вашем запросе используются три из пяти проиндексированных столбцов.Но поскольку в STATUS
есть выражение NOT IN, оптимизатор не использует индекс для оценки фильтра.Таким образом, он читает каждую запись в TRX_T
, которая соответствует записи в TRX_SUB
, и оценивает фильтр в таблице.
Возможно, если вы положительно выразили условие как TT.STATUS IN ('D','J','L', 'S')
, тогда оптимизатор сможет использовать SKIP SCAN для оценки фильтра по индексу.
Однако использование индекса было бы более эффективным, если бы TRX_T.TYPE
использовался в качестве фильтра (или если порядок столбцов индекса был перестроен так, чтобы иметь STATUS
до TYPE
, но несделать это, так как это может дестабилизировать другие запросы).
Другой вариант - переписать выражение как подзапрос NOT IN (если у вас есть no нулевые значения в (TRX_T.CODE, TRX_T.SUBID)
, иначе как подзапрос NOT EXISTS):
select * from TRX_T TT, TRX_SUB TS
where TT.CODE=TS.CODE
and TT.SUBID= TS.ID
and TS.VALUE=1
and TS.CODE=1
AND TS.ID=17
AND (TT.CODE, TT.SUBID) NOT IN
(select x.CODE, x.SUBID
from trx_t x
where x.status in ('T','R','C')
)
Однако количество записей TRX_T, имеющих значения STATUS в этом списке, очень велико - они составляют большую часть вашей таблицы - поэтому оценка того, что подзапрос может оказаться более дорогостоящим, чем то, что у вас есть в данный момент.
Обратите внимание, что применяются обычные оговорки.Настройка запросов на StackOverflow - игра в кружки.Слишком много информации отсутствует (объемы данных, перекос, другие индексы, планы объяснения и т. Д.), Чтобы мы могли делать что-то кроме догадок.