|
|
|
Опять CBO...
|
|||
|---|---|---|---|
|
#18+
Делаю простенький запрос к одной таблице select /*+ALL_ROWS*/ rowid,f1,f2,f3... from t1 where ff1 = :p1 and ff2 = :p2 order by ff2 Есть неуникальный индекс по полям ff1 и ff2. В таблице три записи, и значения полей для ff1 и ff2 во всех записях одинаковые. Имею ли я право расчитывать, что в результате получу записи в порядке возрастания rowid? Дело в том, что до сбора статистики по таблице порядок непредсказуем. После сбора статистики я получаю в порядке возрастания rowid. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2003, 14:22 |
|
||
|
Опять CBO...
|
|||
|---|---|---|---|
|
#18+
Вы получите записи в порядке, определяемом "order by ff2". Все остальные предположения - от лукавого ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2003, 14:46 |
|
||
|
Опять CBO...
|
|||
|---|---|---|---|
|
#18+
Я тоже сомневался, а потом прочитал в доке о внутреннем устройстве индексов.Цитата:"For a nonunique index, the rowid is included in the key in sorted order, so nonunique indexes are sorted by the index key and rowid. " ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2003, 18:15 |
|
||
|
Опять CBO...
|
|||
|---|---|---|---|
|
#18+
Может и поменяло бы, если б Вы явно не указали сортировку в order by. IMHO она является приоритетным ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2003, 13:02 |
|
||
|
Опять CBO...
|
|||
|---|---|---|---|
|
#18+
Несмотря на абсолютную бесполезность данного познания :-) провел маленькое исследование. Итог - нет рассчитывать нельзя. Из таблички с парой неуникальных индексов селектил rowid , хинтом заставляя использовать full index scan . Rowid выбирались неупорядоченно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2003, 13:28 |
|
||
|
Опять CBO...
|
|||
|---|---|---|---|
|
#18+
2Bagira: Конечно, сортировка order by является приоритетной. Я лишь говорю о том, что если значения всех полей в неуникальном индексе совпадает, то сортироватся должно по rowid, что и нашел в документации("They are sorted by (key, ROWID).") 2ora600: Значит в документации врут? Или я неправильно что-то понимаю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2003, 13:43 |
|
||
|
Опять CBO...
|
|||
|---|---|---|---|
|
#18+
Хотя нет, упорядоченность есть. Естественно, по принципу "group by" select /*+ index(t idx)*/ col, rowid from t где idx - индекс по col только сортировка внутри ключа какая-то не совсем понятная 'A' < 'a' < '1' < '+' ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2003, 13:55 |
|
||
|
Опять CBO...
|
|||
|---|---|---|---|
|
#18+
2Korobok Нет, не врут Извини, я просто не совсем врубился, что именно ты хочешь выяснить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2003, 14:01 |
|
||
|
Опять CBO...
|
|||
|---|---|---|---|
|
#18+
Вот я и говорю, что иногда это дело не срабатывает, пока не расчитаешь статистику. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2003, 15:08 |
|
||
|
Опять CBO...
|
|||
|---|---|---|---|
|
#18+
Путаешь причину и следствие: причина - план запроса (использование индекса) следствие - до сбора статистики был не использующий индекс план ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2003, 15:15 |
|
||
|
Опять CBO...
|
|||
|---|---|---|---|
|
#18+
Да, вполне вероятно, что так и происходит. Но я посмотрел план до и после расчета статистики. И в том и другом случае делается table access full. Единственное отличие в размере bytes. После расчета статистики это число уменьшается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2003, 15:21 |
|
||
|
|
start [/forum/topic.php?fid=52&fpage=2794&tid=1991181]: |
0ms |
get settings: |
4ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
44ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
29ms |
get tp. blocked users: |
1ms |
| others: | 200ms |
| total: | 297ms |
| 0 / 0 |
