|
|
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
Oracle 8.1.7 win2000sp3 Есть табличка Код: plaintext 1. 2. 3. 4. 5. 6. 7. и есть уникальный индекс Код: plaintext пишу запрос: Код: plaintext 1. 2. 3. 4. 5. 6. при любом режиме оптимизатора сканируется уникальный индекс немного модифицируем Код: plaintext 1. 2. 3. 4. 5. 6. и оптимизатор падает в панику : TABLE ACCESS FULL обьясните пожалуйста, почему так происходит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 10:10:25 |
|
||
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. Для чего ты используешь NVL, когда у тебя конкретные значения указаны и явно не NULL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 10:16:22 |
|
||
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
1. Юникальный индекс из пяти значений - это слишком много... 2. План похоже меняется, поскольку оптимизатор не может гарантировать результат через индексный доступ в случае, когда во всех столбцах индекса будет NULL. Т.е. в данном случае думаю, что оптимизатор не учитывает, что в nvl'ax стоят литералы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 10:24:40 |
|
||
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
можешь проверить - в втором примере добавить в кляузу where условие and branch_id is not NULL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 10:26:29 |
|
||
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
в реальной ситуации там переменные, передаваемые через процедуру в качестве параметров. Я просто пытался промоделировать данный запрос и не совсем понимаю, как влияет nvl именно для Branch_id. Для всех остальных полей присутствие nvl никак не сказывается на выборе оптимизатора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 10:26:47 |
|
||
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
я думаю, что у него и в первом то случае where Branch_id = '664' индекс подхватывается только для столбца Branch_id, благо он первый в индексе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 10:28:16 |
|
||
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
to killed пробовал, не помагает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 10:28:57 |
|
||
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
to softbuilder похоже на правду, т.е. происходит RANGE SCAN по первой составляющей индекса. Если убираю все nvl, то происходит UNIQUE SCAN. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 10:33:51 |
|
||
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
А если CHAR на VARCHAR2 поменять - тоже самое получается? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 10:35:57 |
|
||
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
to softbuilder к сожалению я не могу менять структуру базы. А чем мотивируется данная замена в этой ситуации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 10:43:01 |
|
||
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
Мотивировка в следующем: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 10:46:43 |
|
||
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 10:48:35 |
|
||
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
Индекс будет подцепляться толкько тогда, когда индексированный столбец указан с одной стороны выражения и по другую сторону выражения нет столбцов этой же таблицы. Т.е. при branch_id='2134' индекс может быть задействован, а при branch_id=branch_id уже индекс работать не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 10:58:35 |
|
||
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
С моей стороны, это только предположение. Создай копию этой таблицы с индексами, только с полями VARCHAR2 и проверь на ней. Совсем не обязательно заполнять всеми данными из рабочей таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 11:03:13 |
|
||
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
to va_kochnev Спвсибо, очень похоже на правду если пишу Код: plaintext то индекс подхватывается. nvl получается тут ни при чём. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 11:04:30 |
|
||
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
Если уж непременно хочется, чтобы работало по индексу то выражение Branch_id = nvl('664',Branch_id) можно преобразовать в branch_id between nvl(<параметр>,<минимально возможное значение branch_id>) and nvl(<параметр>,<максимально возможное значение branch_id>) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 11:49:52 |
|
||
|
не подхватывается индекс
|
|||
|---|---|---|---|
|
#18+
I did not have my coffee yet, so can someone explain me what is the reason (unless it is pure experiment) for expressions like nvl('9900135',Customer_id) which always results in '9900135'. Another words, condition Customer_id = nvl('9900135',Customer_id) is nothing more but a very twisted way to say Customer_id = '9900135'. So if you want to test optimizer IQ, it obviously did not pass this one. Otherwise it would realize that NVL of a constant is a constant itself and therfore would use index UNIQUE SCAN. However, it is smart enough to know that NVL, in general, can result in its second operand which in this case is NULLABLE Customer_id column. As a result, it can not use UNIQUE SCAN and either decides todo RANGE SCAN (by Branch_id = '664') or FULL SCAN if statistics suggests so (or if it is "because I feel like it" we all know optimizer often has a mind of its own :-) ). Artist formerly known as SY. P.S. Another early morning surprize. Someone stole my identity and registered as SY. So if you see some nonsense from SY - it is not me, but if is something smart, yes it is me :-). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 16:22:22 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=32171558&tid=1990277]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
197ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 229ms |
| total: | 500ms |

| 0 / 0 |
