Suddenly I saw a saying on the Internet that the WHERE condition execution sequence of Oracle is from right to left.
The reason is that when multiple 00904 characters in the WHERE condition of ORACLE are invalid, the error is returned in the order from right to left.
Some people suggested that the resolution sequence and execution sequence are not the same. The execution sequence depends on the execution plan.
So I made a special test.
Now we have a test table.
SQL> select count (*) from dba_objects;
COUNT (*)
----------
72536
Create table dba_objects2 as select * from dba_objects;
First Query
SQL> select object_id, object_name from dba_objects2 where owner = 'hr' and object_id> 500;
41 rows have been selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 4278809457
----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (% CPU) | Time |
----------------------------------------------------------------------------------
| 0 | select statement | 426 | 40896 | 283 (1) | 00:00:04 |
| * 1 | table access full | DBA_OBJECTS2 | 426 | 40896 | 283 (1) | 00:00:04 |
----------------------------------------------------------------------------------
Predicate Information (identified by operation id ):
---------------------------------------------------
1-filter ("OWNER" = 'hr' AND "OBJECT_ID"> 500)
Note
-----
-Dynamic sampling used for this statement (level = 2)
We can see that Oracle is executed from left to right this time. What if SQL statements are reversed?
SQL> select object_id, object_name from dba_objects2 where object_id> 500 and owner = 'hr ';
41 rows have been selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 4278809457
----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (% CPU) | Time |
----------------------------------------------------------------------------------
| 0 | select statement | 426 | 40896 | 283 (1) | 00:00:04 |
| * 1 | table access full | DBA_OBJECTS2 | 426 | 40896 | 283 (1) | 00:00:04 |
----------------------------------------------------------------------------------
Predicate Information (identified by operation id ):
---------------------------------------------------
1-filter ("OWNER" = 'hr' AND "OBJECT_ID"> 500)
Note
-----
-Dynamic sampling used for this statement (level = 2)
The actual execution order is from right to left. Is the execution sequence of oracle overhead? Place as many conditions as possible to narrow the data range before execution.
I added another condition to prove my idea.
SQL> select object_id, object_name from dba_objects2 where object_id> 500 and object_name like '% EM %' and owner = 'hr ';
14 rows have been selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 4278809457
----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (% CPU) | Time |
----------------------------------------------------------------------------------
| 0 | select statement | 147 | 14112 | 283 (1) | 00:00:04 |
| * 1 | table access full | DBA_OBJECTS2 | 147 | 14112 | 283 (1) | 00:00:04 |
----------------------------------------------------------------------------------
Predicate Information (identified by operation id ):
---------------------------------------------------
1-filter ("OBJECT_NAME" is not null and "OWNER" = 'hr' AND
"OBJECT_ID"> 500 AND "OBJECT_NAME" LIKE '% EM % ')
Note
-----
-Dynamic sampling used for this statement (level = 2)
ORACLE intelligence adds the condition "OBJECT_NAME" is not null, and puts OBJECT_NAME "LIKE '% EM %' in the middle for final execution.
It can be seen that the execution sequence of the WHERE condition is intelligently adjusted according to the order in which the overhead is right to large.