INDEX HINT not working

Yanvladimirovich

Привет. А как может быть такое?

Дамп из ST05, имеем хинт INDEX( "MSEG" "MSEG~Z6" ) но INDEX RANGE SCAN MSEG~Z5

Code:

SQL Statement
SELECT
/*+
  INDEX( "MSEG" "MSEG~Z6" )
*/
  T_00."BWART", T_00."MATNR"
FROM
  "MSEG" T_00 INNER JOIN "MKPF" T_01 ON T_01."MANDT"=:A0 AND T_00."MBLNR"=T_01."MBLNR" AND T_00."MJA
  HR"=T_01."MJAHR"
WHERE
  T_00."MANDT"=:A1 AND T_01."BUDAT">=:A2 AND T_00."MJAHR"=:A3 AND T_00."BWART"=:A4 AND T_00."WERKS"=
  :A5 AND T_00."MBLNR">=:A6 AND T_00."MBLNR"<=:A7


Execution Plan

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 SELECT STATEMENT ( Estimated Costs = 12 , Estimated #Rows = 4 )
  |
  ---   6 FILTER
      |   Filter Predicates
      |
      ---   5 NESTED LOOPS
          |
          |--   3 NESTED LOOPS
          |   |   ( Estim. Costs = 12 , Estim. #Rows = 4 )
          |   |   Estim. CPU-Costs = 96.227 Estim. IO-Costs = 12
          |   |
          |   |-----1 INDEX RANGE SCAN MSEG~Z5
          |   |       ( Estim. Costs = 4 , Estim. #Rows = 4 )
          |   |       Search Columns: 5
          |   |       Estim. CPU-Costs = 30.086 Estim. IO-Costs = 4
          |   |       Access Predicates
          |   ------2 INDEX UNIQUE SCAN MKPF~0
          |           ( Estim. Costs = 1 , Estim. #Rows = 1 )
          |           Search Columns: 3
          |           Estim. CPU-Costs = 9.074 Estim. IO-Costs = 1
          |           Access Predicates Filter Predicates
          |
          ------4 TABLE ACCESS BY INDEX ROWID MKPF
                  ( Estim. Costs = 2 , Estim. #Rows = 1 )
                  Estim. CPU-Costs = 16.535 Estim. IO-Costs = 2
                  Filter Predicates

trop

а какие поля в индексах z5, z6 ?
и ещё запрос в виде opensql

скорее всего из-за >=, <=

Yanvladimirovich

Во всех индексах Z3...Z7 одинаковый набор полей, но порядок полей разный. Пытаюсь понять, какой порядок лучше работает, это не очевидно.

А, да, важное. Когда я в ST05 ставлю Explain with hint, и ставлю hint на Full Scan, оно тоже не работает.

Кодер

Покажите абап-код. Там был прикол, что нужно указывать не имя таблы, а имя алиаса из джойна. Причем именно то имя алиаса, которое показывается в st05(T_00, T_01)

trop

раз не приводите open sql, считаем ,что хинт написан правильно.
для индекса вероятно лучше указывать наиболее узкий критерий последним (листьевой ключ),
с точки зрения экономии, с другой стороный если есть достаточно узкий критерий, то можно
создать индекс только с этим полем (mandt + критерий).
наверное это настраивается - оптимизатор иногда выбирает из 2х индексов
наиболее подходящий по статистике, игнорируя хинт -
from A inner join B,
в условиях A указан хинт, но оптимизатор выбирает B как первичную таблицу,
вероятно из-за того, что в ней меньше записей, или в B есть более привлекательный индекс чем хинт A

Yanvladimirovich

Прошу прощения, я тут работал :-)

Вот код, точнее не тот самый - но этот же чуть чуть поправленый (заменились условия на ренджи)

Алиасов нет

Индекс создаётся по полям

MSEG: MANDT MJAHR BWART WERKS MBLNR MATNR
MKPF: BUDAT MBLNR MJAHR

Если индекс подхватывается, всё работает очень быстро. Если нет, умирает на долго.

Цитата:

SELECT WERKS MATNR
FROM MSEG
JOIN MKPF
ON MSEG~MBLNR = MKPF~MBLNR
AND MSEG~MJAHR = MKPF~MJAHR
INTO TABLE it_matnrwerks PACKAGE SIZE i_packagesize
WHERE
MKPF~BUDAT IN SO_DATE AND
MSEG~MJAHR = il_mblnr-MJAHR AND
MSEG~BWART = '251' AND
MSEG~WERKS IN SO_WERKS AND
MSEG~MBLNR >= il_mblnr-MBLNR_MIN AND
MSEG~MBLNR <= il_mblnr-MBLNR_MAX
ORDER BY MATNR WERKS
%_HINTS ORACLE 'INDEX("MSEG" "MSEG~Z6")'.

В принципе, сейчас проблема только что если в код добавить ещё один JOIN с MARA, то он умирает. Приходится реализовывать JOIN по внутренней таблице.

trop

оба индекса включают в себя первичный ключ..
вот пример, если создать вторичный индекс на часть полей из первичного ключа,
то быстрее выборка работать вероятно не станет,
B-дерево и в том и в другом случае будет иметь одинаковую часть.
то есть индекс, включающий в себя начало другого, иногда излишний.

кому понадобились такие странные данные ..
для такого запроса, можно проверить есть ли индексы -
mkpf (mandt, budat) и mseg (mandt,bwart,werks),
поле matnr в условиях не используется, а поиск индекса ведётся по
заполненным критериям из where.
order by можно не добавлять в запрос, это немного замедляет выборку,
можно по результату сделать sort и delete adjacent duplicates.

хинт можно закомментировать и посмотреть, что сделает оптимизатор.

Crystal_Ra

вставлю свои пять копеек.
Я бы потратил время на соответствие порядка выбираемых данных порядку в таблицах...
и в условиях - порядку в индексах (ключах)
а потом план еще разик посмотреть без хинта.

возможно вперед поставить ту таблицу которая дает меньшее множество?

Ваши ренджи не "должны" иметь like`s - всё так?

ArmAnn

А еще пересоберите статистику на всякий случай

Кодер

2 Yanvladimirovich: все правильно, у Вас алиасы - не указаны. А вот DBI сап, когда из openSQL конвертит джойн в SQL понятный субд накручивает алиас сам(причем на ваши алиасы ему будет плеать), см. вашу трассу в st05.
Поэтому в вашем случае нужно указывать вот так

Цитата:

%_HINTS ORACLE 'INDEX("T_00" "T_00~Z6")'.

Yanvladimirovich

Поправил, даже версия %_HINTS ORACLE 'INDEX("T_00" "MSEG~Z6")'. работает.

А алисасы точно всегда прописываются в порядке того, как таблица идёт в запросе?

Кодер

2 Yanvladimirovich: нету у меня ответа на этот вопрос. Это надо авторов DBI спрашивать. Но я на всякий пожарный воткнул еще один хинт ORDERED чтоли (сейчас системы под рукой нет посмотреть), он говорит оре, что надо брать таблы в той последовательности, как они перечислены в запросе.

Pavel Berezin

жутковатый какойто запрос (и индексы похоже такиеже

).

А что в нём не устраивает - стоимость вроде невелика?
И кстати, значения переменных какие (план надеюсь реальный, не из Explain)?

Правила форума

INDEX HINT not working

Кто сейчас на конференции