|
|
|
Внутренняя структура B-tree составного индекса
|
|||
|---|---|---|---|
|
#18+
Есть запрос вида: Код: plsql 1. 2. 3. 4. 5. Есть индекс вида: Код: plsql 1. Будет ли при прочих равных для данного запроса эффективнее индекс такого вида: Код: plsql 1. Т.е. f6 перетащить ближе к "началу", дабы все ключи для конкретного набора значений предикатов как бы находились рядом? Сам считаю, что это было бы разумным и само собой разумеющимся, но, если например уже по f1 подбираются все данные из одного блока, то выигрыш можно получить только в логических чтениях, но так ли он велик, решает конкретная ситуация. Сильно ли ошибаюсь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2016, 15:52:41 |
|
||
|
Внутренняя структура B-tree составного индекса
|
|||
|---|---|---|---|
|
#18+
ВзамешательствеСильно ли ошибаюсь? похоже, да ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2016, 16:57:38 |
|
||
|
Внутренняя структура B-tree составного индекса
|
|||
|---|---|---|---|
|
#18+
прошу прощения ответил не на тот вопрос.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2016, 16:59:31 |
|
||
|
Внутренняя структура B-tree составного индекса
|
|||
|---|---|---|---|
|
#18+
ВзамешательствеСильно ли ошибаюсь? в данном случае практически не ошибаешься. индексный ключ это по сути сконкатенированные (склеенные) в одну строку значения составляющих полей, плюс на конце строки висит rowid запрос выше не потребует range skip scan при индексе f1, f2, f6, но учитывая высокую селективность f1, f2 эффекта может и не быть вообще ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2016, 18:34:50 |
|
||
|
|
start [/forum/topic.php?fid=52&msg=39281478&tid=1887788]: |
0ms |
get settings: |
7ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
232ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 192ms |
| total: | 510ms |
| 0 / 0 |
