запрос в ORACLE

← →
rus0303 (2006-06-25 22:41) [0]

IX Есть оператор

select * fromTABLE1, TABLE2 WHERE table1.col1=table2.col2

в таблице table2 по полю col2 есть индекс table2$col2$IDX
Посмотрев на план исполнения, вы понимаете, что этот индекс не используется. Как лучше заставить его использоваться. Очень срочно. помогите пожалуйста.

← →
rus0303 (2006-06-25 22:57) [1]

Пожалуйста ответьте, очень срочно и очень надо. ГОРИТ!!!

← →
Пусик © (2006-06-25 23:04) [2]

Попробуй покопать в сторону
SELECT /* +RULE */

← →
softservice © (2006-06-26 02:55) [3]

> IX Есть оператор
>
> select * fromTABLE1, TABLE2 WHERE table1.col1=table2.col2
>
>
> в таблице table2 по полю col2 есть индекс table2$col2$IDX
> Посмотрев на план исполнения, вы понимаете, что этот индекс
> не используется. Как лучше заставить его использоваться.
> Очень срочно. помогите пожалуйста.

Никак в принципе, так как выборка будет идти из Table1, а в ней индекса нету. Либо переделать запрос, либо построить индекс по Table1.Col1

← →
Sergey13 © (2006-06-26 09:00) [4]

2[0] rus0303 (25.06.06 22:41)
>Как лучше заставить его использоваться.
А зачем? Может индекс плохой и оптимизатор сознательно его не использует.

← →
evvcom © (2006-06-26 09:33) [5]

> Никак в принципе, так как выборка будет идти из Table1,
> а в ней индекса нету

Table1 тут совсем не причем. Можно заставить TABLE FULL SCAN по таблице Table1 и INDEX SCAN по Table2.

> Может индекс плохой и оптимизатор сознательно его не использует.

Так и есть. Поскольку выбираются ВСЕ столбцы Table2, а индекс, видимо, не содержит их всех, то так или иначе за данными все равно придется лезть в таблицу. Кроме того, в запросе не указано, что выбираться будет часть данных. Выберутся все данные. А раз так, накой оптимизатору читать индекс, а потом в этой последовательности еще и читать данные, причем наверняка некоторые блоки придется читать по два и более раз. В итого TABLE FULL SCAN будет гораздо дешевле.
Замечено, что при оценочной выборке 10 и более % оптимизатор НИКОГДА не остановится на выборе индекса, если индекс не содержит всех требуемых в запросе полей.

← →
Кщд © (2006-06-26 09:38) [6]

> SELECT /* +RULE */

конкретно этот кусочек вообще ни на что не повлияет :)
да и сам Oracle больше CBO любит

← →
Sergey13 © (2006-06-26 09:40) [7]

Все может быть и проще. Т2 - просто маленькая таблица.

← →
Sergey13 © (2006-06-26 10:01) [8]

> [6] Кщд © (26.06.06 09:38)
> > SELECT /* +RULE */
> конкретно этот кусочек вообще ни на что не повлияет :)

Почему? Это отрубит СВО и если есть подходящий индекс, он заюзается.

> [7] Sergey13 © (26.06.06 09:40)
> Т2 - просто маленькая таблица.

Или СВО думает, что она маленькая, потому что статистика по ней собиралась давным давно.

← →
Кщд © (2006-06-26 10:44) [9]

> Почему? Это отрубит СВО и если есть подходящий индекс, он
> заюзается.

плюсик чутку правее, чем надо :)

> Или СВО думает, что она маленькая, потому что статистика
> по ней собиралась давным давно.

10g активно пытается забыть про RBO и для сбора статистики выделен спец. процессик

← →
Sergey13 © (2006-06-26 11:07) [10]

2[9] Кщд © (26.06.06 10:44)
>10g активно пытается забыть про RBO
Начиная с 8i, насколько я помню, пытается. Попытки пока особым успехом не увенчались. 8-)

← →
evvcom © (2006-06-26 11:07) [11]

> Т2 - просто маленькая таблица
> Или СВО думает, что она маленькая

В итоге "to be or not to be" упирается в оценочный % селективности. В случае автора селективность 100% и выборка всех столбцов. О каком индексе может идти речь? Никакая статистика не спасет.

← →
Sergey13 © (2006-06-26 11:13) [12]

> [11] evvcom © (26.06.06 11:07)

Если таблица большая, то индекс юзается для соединения с другой. Если же она "маленькая", то проще сразу ее всю прочитать (без индекса) и соединять "в памяти".
Кроме того, насколько я помню, селективность - это не то сколько всего записей выбирается вообще, а то сколько % записей выбирается для определенного значения.

> [12] Sergey13 © (26.06.06 11:13)

Да разницы в этом плане нет, большая или маленькая. Если используется только поле соединения, то оно и возьмется из индекса хоть для большой, хоть для маленькой (хотя в этом случае целесообразность такого запроса сомнительна). В большинстве случаев физически из индекса меньше придется читать.
Надеюсь, маленькой в данном случае мы не называем таблицу из одной-двух записей? :)

> а то сколько % записей выбирается для определенного значения

не особо понял, что ты имеешь ввиду. Селективность - именно сколько записей выберется в данном запросе из данной таблицы, деленное на общее количество записей в этой таблице. Это как я понял этот термин. И если оптимизатор оценит ее в 10 и более %, то по индексу не пойдет.

Пусик © (25.06.06 23:04) [2]
> Попробуй покопать в сторону
> SELECT /* +RULE */
Если уж пользоваться хинтами (что не рекомендуется), то лучше указать хинт на использование желаемого индекса, чем абстрактный, да еще и неправильно написанный хинт разбора по правилам.

> [13] evvcom © (26.06.06 11:47)

Есть селективность запроса, а есть селективность индекса. Если в таблице проиндексировано поле "Пол", имеющее (в большинстве случаев 8-) всего 2 значения, такой индекс юзаться не будет практически никогда.
Если в сабжевом запросе выбираются все записи, и обе таблицы "приличные" по размеру, то соединить их без индекса будет, ИМХО, более затратно, чем по индексу. Иначе придется прочитать обе в память и все равно построить индекс для поиска в одной из них. По крайне мере у меня план подобного запроса выдает использование индекса.

> такой индекс юзаться не будет практически никогда

Согласен

> обе таблицы "приличные" по размеру, то соединить их без
> индекса будет, ИМХО, более затратно, чем по индексу

это если оптимизатор выберет MERGE JOIN (когда отключено разрешение выбирать HASH JOIN) и выберет все же индекс. Если же будет выбран NESTED LOOPS JOIN (если есть маленькая таблица) или HASH JOIN, то индекс здесь по барабану.

> Иначе придется прочитать обе в память и все равно построить
> индекс для поиска в одной из них

В соединении HASH JOIN примерно так и делается, при том на больших таблицах именно это соединение является наиболее быстрым.

> По крайне мере у меня план подобного запроса выдает использование индекса.

Запрос приведи, обсудим.

> Запрос приведи, обсудим.

Ну и ориентировочное кол-во записей, а также SQL индекса

запрос в ORACLE Найти похожие ветки