Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

запрос в ORACLE


rus0303 ©   (2006-06-25 22:41:00) 

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

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

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


evvcom   (2006-06-26 14:32:00) [1]

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

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


evvcom   (2006-06-26 14:31:00) [2]

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

Согласен

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

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

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

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

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

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


Sergey13   (2006-06-26 12:02:00) [3]

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

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


Desdechado   (2006-06-26 11:55:00) [4]

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


evvcom   (2006-06-26 11:47:00) [5]

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

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

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

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


Sergey13   (2006-06-26 11:13:00) [6]

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

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


evvcom   (2006-06-26 11:07:00) [7]

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

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


Sergey13   (2006-06-26 11:07:00) [8]

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


Кщд   (2006-06-26 10:44:00) [9]


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

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


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

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


Sergey13   (2006-06-26 10:01:00) [10]

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

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

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

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


Sergey13   (2006-06-26 09:40:00) [11]

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


Кщд   (2006-06-26 09:38:00) [12]


> SELECT /* +RULE */

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


evvcom   (2006-06-26 09:33:00) [13]

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

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

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

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


Sergey13   (2006-06-26 09:00:00) [14]

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


softservice   (2006-06-26 02:55:00) [15]


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

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


Пусик   (2006-06-25 23:04:00) [16]

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


rus0303   (2006-06-25 22:57:00) [17]

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


Наверх

Титульная страница Поиск, карта сайта Написать письмо