Oracle 索引和执行计划
建了个测试的数据表,想测试建了索引和不建立索引的区别。建立表的数据量为108631962行。每次插入9999999行,每次大概半个小时。
建了个测试的数据表,想测试建了索引和不建立索引的区别。建立表的数据量为108631962行。每次插入9999999行,每次大概半个小时。在id上建立索引,,花时间为37秒,不建立索引花时间为:1分58秒。演示如下所示:
SQL> insert into studyindex1 select rownum id,'db'dbms_random.value(
2 1,100) name,dbms_random.string('X',20) remark from dual connect by level000000;
已创建9999999行。
SQL> commit;
提交完成。
SQL> select count(*) from studyindex1;
COUNT()
----------
108631962
12:13:22 SQL> create index id_idx on studyindex1(id);
索引已创建。
14:19:32 SQL> commit;
提交完成。
14:22:51 SQL> select id,name,remark from studyindex1 where id=203;
已选择38行。
执行计划
----------------------------------------------------------
Plan hash value: 2350744396
--------------------------------------------------------------------------------
-----------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
Time |
--------------------------------------------------------------------------------
-----------
| 0 | SELECT STATEMENT | | 38 | 77444 | 43 (0)|
00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| STUDYINDEX1| 38 | 77444 | 43 (0)|
00:00:01 |
|* 2 | INDEX RANGE SCAN | ID_IDX | 38 | | 3 (0)|
00:00:01 |
--------------------------------------------------------------------------------
-----------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("ID"=203)
Note
-----
- dynamic sampling used for this statement
统计信息
----------------------------------------------------------
9 recursive calls
0 db block gets
154 consistent gets
312 physical reads
0 redo size
3663 bytes sent via SQL*Net to client
514 bytes received via SQL*Net from client
4 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
38 rows processed
14:23:28 SQL> drop index id_idx;
索引已删除。
14:24:15 SQL> commit;
提交完成。
14:24:21 SQL> select id,name,remark from studyindex1 where id=203;
已选择38行。
执行计划
----------------------------------------------------------
Plan hash value: 469406081
--------------------------------------------------------------------------------
-
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
--------------------------------------------------------------------------------
-
| 0 | SELECT STATEMENT | | 12417 | 24M| 248K (1)| 00:49:47
|
|* 1 | TABLE ACCESS FULL| STUDYINDEX1| 12417 | 24M| 248K (1)| 00:49:47
|
--------------------------------------------------------------------------------
-
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ID"=203)
Note
-----
- dynamic sampling used for this statement
统计信息
----------------------------------------------------------
169 recursive calls
0 db block gets
1121670 consistent gets
1053183 physical reads
0 redo size
3663 bytes sent via SQL*Net to client
514 bytes received via SQL*Net from client
4 SQL*Net roundtrips to/from client
4 sorts (memory)
0 sorts (disk)
38 rows processed
14:26:19 SQL>

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.
