Oracle WHER条件的执行顺序是不是自右向左
突然在网上看到一种说法,ORACLE的WHERE条件执行顺序是自右向左的。理由是,当ORACLE的WHERE条件中出现多个00904表示符无效错误时
突然在网上看到一种说法,Oracle的WHERE条件执行顺序是自右向左的。
理由是,当ORACLE的WHERE条件中出现多个00904表示符无效错误时,错误是从右向左的顺序报的。
也有人提出解析顺序和执行顺序不是一码事,执行顺序要看执行计划。
于是,我特地作了个试验。
现做一个试验用表
SQL> select count(*) from dba_objects;
COUNT(*)
----------
72536
create table dba_objects2 as select * from dba_objects;
先来一次查询
SQL> select object_id,object_name from dba_objects2 where owner='HR' and object_id>500;
已选择41行。
执行计划
----------------------------------------------------------
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)
可以看出,这次Oracle是自左向右执行。那么SQL语句颠倒下会怎样?
SQL> select object_id,object_name from dba_objects2 where object_id>500 and owner='HR';
已选择41行。
执行计划
----------------------------------------------------------
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)
实际的执行顺序是自右向左。难道oracle的执行顺序是看开销的?把尽可能多缩小数据范围的条件放在前面执行。
为了证明自己的想法,我又增加了一个条件。
SQL> select object_id,object_name from dba_objects2 where object_id>500 and object_name like '%EM%' and owner='HR';
已选择14行。
执行计划
----------------------------------------------------------
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 智能的增加了"OBJECT_NAME" IS NOT NULL的条件,把放在中间的 OBJECT_NAME" LIKE '%EM%'放在了最后执行。
由此可见,,WHERE条件的执行顺序是按照开销的右小到大的顺序,智能调节的。
本文永久更新链接地址:

Alat AI Hot

Undresser.AI Undress
Apl berkuasa AI untuk mencipta foto bogel yang realistik

AI Clothes Remover
Alat AI dalam talian untuk mengeluarkan pakaian daripada foto.

Undress AI Tool
Gambar buka pakaian secara percuma

Clothoff.io
Penyingkiran pakaian AI

AI Hentai Generator
Menjana ai hentai secara percuma.

Artikel Panas

Alat panas

Notepad++7.3.1
Editor kod yang mudah digunakan dan percuma

SublimeText3 versi Cina
Versi Cina, sangat mudah digunakan

Hantar Studio 13.0.1
Persekitaran pembangunan bersepadu PHP yang berkuasa

Dreamweaver CS6
Alat pembangunan web visual

SublimeText3 versi Mac
Perisian penyuntingan kod peringkat Tuhan (SublimeText3)

Topik panas



Artikel ini membincangkan menggunakan pernyataan jadual Alter MySQL untuk mengubah suai jadual, termasuk menambah/menjatuhkan lajur, menamakan semula jadual/lajur, dan menukar jenis data lajur.

Keupayaan carian teks penuh InnoDB sangat kuat, yang dapat meningkatkan kecekapan pertanyaan pangkalan data dan keupayaan untuk memproses sejumlah besar data teks. 1) InnoDB melaksanakan carian teks penuh melalui pengindeksan terbalik, menyokong pertanyaan carian asas dan maju. 2) Gunakan perlawanan dan terhadap kata kunci untuk mencari, menyokong mod boolean dan carian frasa. 3) Kaedah pengoptimuman termasuk menggunakan teknologi segmentasi perkataan, membina semula indeks dan menyesuaikan saiz cache untuk meningkatkan prestasi dan ketepatan.

Artikel membincangkan mengkonfigurasi penyulitan SSL/TLS untuk MySQL, termasuk penjanaan sijil dan pengesahan. Isu utama menggunakan implikasi keselamatan sijil yang ditandatangani sendiri. [Kira-kira aksara: 159]

Artikel membincangkan alat MySQL GUI yang popular seperti MySQL Workbench dan PHPMyAdmin, membandingkan ciri dan kesesuaian mereka untuk pemula dan pengguna maju. [159 aksara]

Artikel membincangkan strategi untuk mengendalikan dataset besar di MySQL, termasuk pembahagian, sharding, pengindeksan, dan pengoptimuman pertanyaan.

Artikel ini membincangkan jadual menjatuhkan di MySQL menggunakan pernyataan Jadual Drop, menekankan langkah berjaga -jaga dan risiko. Ia menyoroti bahawa tindakan itu tidak dapat dipulihkan tanpa sandaran, memperincikan kaedah pemulihan dan bahaya persekitaran pengeluaran yang berpotensi.

MySQL menyokong empat jenis indeks: B-Tree, Hash, Full-Text, dan Spatial. 1. B-Tree Index sesuai untuk carian nilai yang sama, pertanyaan dan penyortiran. 2. Indeks hash sesuai untuk carian nilai yang sama, tetapi tidak menyokong pertanyaan dan penyortiran pelbagai. 3. Indeks teks penuh digunakan untuk carian teks penuh dan sesuai untuk memproses sejumlah besar data teks. 4. Indeks spatial digunakan untuk pertanyaan data geospatial dan sesuai untuk aplikasi GIS.

Artikel ini membincangkan membuat indeks pada lajur JSON dalam pelbagai pangkalan data seperti PostgreSQL, MySQL, dan MongoDB untuk meningkatkan prestasi pertanyaan. Ia menerangkan sintaks dan faedah mengindeks laluan JSON tertentu, dan menyenaraikan sistem pangkalan data yang disokong.
