ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Странное поведение оптимизатора
4 сообщений из 4, страница 1 из 1
Странное поведение оптимизатора
    #39469344
csc.pau
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
csc.pau
Гость
Коллеги, доброго времени суток.
Вчера столкнулся с оочень странной ситуацией.

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
create table kim2
(
id number not null primary key,
code varchar2(50)
);

create unique index ix_kim2 on kim2(code);

create table kim1
(
id number primary key,
ref_id number references kim2(id)
);

insert into kim2
select 1,'a' from dual
union all
select 2,'b' from dual union all
select 3,'c' from dual
;

insert into kim1
select 11,1 from dual union all
select 12,2 from dual union all
select 13,2 from dual union all
select 14,3 from dual;


Собственно примитивный пример. Две таблички, форейн кей из kim1 на kim2. В kim2 поле Code уникальное.

Теперь предположим, что я ошибся в написании запроса к этим двум таблицам, и склеил их не по kim1.ref_id = kim2.id, а kim1.ref_id = kim2.code (собственно так ситуация и обнаружилась).

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
SQL> select kim2.code from kim1
  2  join kim2 on kim1.ref_id = kim2.code;

      CODE                                                                      
----------                                                                      
         1                                                                      
         2                                                                      
         2                                                                      
         3


Собственно, уже на этом моменте я решил, что упоролся.
Смотрим план...
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
PLAN_TABLE_OUTPUT                                                               
--------------------------------------------------------------------------------
Plan hash value: 2912823280                                                     
                                                                                
--------------------------------------------------------------------------      
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |      
--------------------------------------------------------------------------      
|   0 | SELECT STATEMENT  |      |     4 |    52 |     3   (0)| 00:00:01 |      
|   1 |  TABLE ACCESS FULL| KIM1 |     4 |    52 |     3   (0)| 00:00:01 |      
--------------------------------------------------------------------------


То есть в kim2 он не обращался вообще, и просто прочел значения из kim1.ref_id, считая что они будут равны kim2.code (т.к. это условие склейки). Но это посыл неверный, т.к. foreign key то указывает с kim1.ref_id на kim2.id, а не на Code.
Ну и последняя вводная, если дропнуть индекс на уникальность code, запрос сразу работает корректно.
Сразу предварительный план нормальный...
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
PLAN_TABLE_OUTPUT                                                               
--------------------------------------------------------------------------------
Plan hash value: 4042778085                                                     
                                                                                
---------------------------------------------------------------------------     
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |     
---------------------------------------------------------------------------     
|   0 | SELECT STATEMENT   |      |     4 |   160 |     7  (15)| 00:00:01 |     
|*  1 |  HASH JOIN         |      |     4 |   160 |     7  (15)| 00:00:01 |     
|   2 |   TABLE ACCESS FULL| KIM2 |     3 |    81 |     3   (0)| 00:00:01 |     
|   3 |   TABLE ACCESS FULL| KIM1 |     4 |    52 |     3   (0)| 00:00:01 |     
---------------------------------------------------------------------------


И результат предсказуемый...
Код: plsql
1.
2.
3.
4.
5.
6.
SQL> select kim2.code from kim1
  2  join kim2 on kim1.ref_id = kim2.code;
join kim2 on kim1.ref_id = kim2.code
                           *
ошибка в строке 2:
ORA-01722: неверное число
...
Рейтинг: 0 / 0
09.06.2017, 12:07
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора
    #39469348
csc.pau
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
csc.pau
Гость
Собственно, перечитал написанное, и понял, что слово "Собственно" стало словом-паразитом у меня...но это оффтоп)
...
Рейтинг: 0 / 0
09.06.2017, 12:09
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора
    #39469358
Фотография dbms_photoshop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbms_photoshop
Участник
csc.pau,

Видимо join elimination на твоей версии некорректно работает.
Можешь поковырять 10053 если интересно.
...
Рейтинг: 0 / 0
09.06.2017, 12:16
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора
    #39469361
Не повторилось
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не повторилось
Гость
11.2.0.3.0
...
Рейтинг: 0 / 0
09.06.2017, 12:19
| Ответить | Цитировать | Написать  
4 сообщений из 4, страница 1 из 1
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Странное поведение оптимизатора
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&msg=39469348&tid=1885786]:
 0ms
get settings:
 5ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 168ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 35ms
get tp. blocked users:
 1ms
others: 218ms
total:  457ms
созд. / загр.: 457ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]