Indeks lajur tunggal MySQL dan ringkasan indeks bersama

Artikel ini membawa anda pengetahuan yang berkaitan tentang mysql terutamanya isu yang berkaitan dengan indeks lajur tunggal dan indeks bersama Menggunakan lajur tambahan dalam indeks boleh mengecilkan skop carian, tetapi Menggunakan indeks dengan dua lajur adalah berbeza daripada menggunakan dua indeks yang berasingan. Mari kita lihat ia akan membantu semua orang.

Pembelajaran yang disyorkan: tutorial video mysql

1. Pengenalan

Menggunakan lajur tambahan dalam indeks, anda boleh Kecilkan carian anda, tetapi menggunakan indeks dengan dua lajur adalah berbeza daripada menggunakan dua indeks berasingan.

Struktur indeks bersama adalah serupa dengan buku telefon Nama seseorang terdiri daripada nama keluarga dan nama yang diberikan Pertama kali diisih mengikut nama keluarga, dan kemudian diisih mengikut nama pertama orang yang mempunyai nama keluarga yang sama. Buku telefon sangat berguna jika anda tahu nama keluarga anda, lebih berguna jika anda tahu nama pertama dan nama keluarga anda, tetapi tidak berguna jika anda hanya tahu nama pertama anda tetapi bukan nama keluarga anda.

Jadi apabila membuat indeks bersama, susunan lajur perlu dipertimbangkan dengan teliti. Indeks kesatuan berguna apabila mencari pada semua lajur dalam indeks atau hanya pada beberapa lajur pertama ia tidak berguna apabila mencari pada mana-mana lajur berikutnya.

2. Indeks lajur tunggal

Apabila berbilang indeks lajur tunggal digunakan untuk pertanyaan berbilang syarat, pengoptimum akan memberi keutamaan kepada strategi indeks optimum. atau ia mungkin menggunakan semua berbilang indeks . Walau bagaimanapun, berbilang indeks lajur tunggal akan mencipta berbilang pepohon indeks B di bahagian bawah, yang mengambil ruang dan membazirkan sejumlah kecekapan carian Oleh itu, adalah lebih baik untuk membina indeks bersama jika terdapat pertanyaan bersama berbilang syarat.

3. Prinsip awalan paling kiri

Seperti namanya, ia adalah keutamaan paling kiri Sebarang indeks berturut-turut bermula dari paling kiri boleh dipadankan jika medan pertama ialah pertanyaan julat dibuat secara berasingan Untuk indeks, apabila mencipta indeks bersama, lajur yang paling kerap digunakan dalam klausa tempat harus diletakkan di sebelah kiri mengikut keperluan perniagaan. Dalam kes ini, kebolehskalaan adalah lebih baik Contohnya, nama pengguna sering digunakan sebagai syarat pertanyaan, tetapi umur tidak selalu digunakan, jadi nama pengguna perlu diletakkan di kedudukan pertama indeks bersama, iaitu, di sebelah kiri. .

1. Buat indeks komposit

ALTER TABLE employee ADD INDEX idx_name_salary (name,salary)

2. Memenuhi ciri paling kiri indeks komposit, walaupun ia hanya sebahagian daripadanya, indeks komposit akan berkuat kuasa

SELECT * FROM employee WHERE NAME='哪吒编程'

3. Ia tidak kelihatan Medan di sebelah kiri tidak memenuhi ciri paling kiri, dan indeks tidak sah

SELECT * FROM employee WHERE salary=5000

4 Indeks komposit digunakan sepenuhnya muncul dalam susunan di sebelah kiri, dan indeks berkuat kuasa

SELECT * FROM employee WHERE NAME='哪吒编程' AND salary=5000

5 , walaupun ia melanggar ciri paling kiri, MySQL akan melakukan pengoptimuman apabila melaksanakan SQL, dan lapisan bawah melakukan pengoptimuman terbalik

SELECT * FROM employee WHERE salary=5000 AND NAME='哪吒编程'

6. Sebab

Indeks komposit juga dipanggil indeks bersama Apabila kita mencipta Apabila indeks bersama digunakan, seperti (k1,k2,k3), ia bersamaan dengan mencipta. tiga indeks (k1), (k1,k2) dan (k1,k2,k3) Ini adalah prinsip padanan paling kiri.

Indeks bersama tidak memenuhi prinsip paling kiri, dan indeks biasanya akan gagal.

4. Terdapat indeks bersama dan indeks lajur tunggal pada masa yang sama (medan diulang. Bagaimanakah indeks akan digunakan untuk menanyakan MySQL pada masa ini).

Ini melibatkan strategi pengoptimum pertanyaan MySQL itu sendiri Apabila jadual mempunyai berbilang indeks, MySQL akan memilih indeks yang hendak digunakan berdasarkan kos pernyataan pertanyaan

Sesetengah orang mengatakan pertanyaan di mana Urutan adalah dari kiri ke kanan, jadi syarat dengan daya saringan yang paling kuat harus diletakkan terlebih dahulu. Baidu Online memang mempunyai kenyataan ini, tetapi saya telah mengujinya secara peribadi Pengoptimum pelaksanaan MySQL akan mengoptimumkannya Apabila indeks tidak dipertimbangkan, susunan keadaan tidak memberi kesan kepada kecekapan ialah sama ada indeksnya digunakan!

5. Intipati indeks bersama

Apabila mencipta indeks bersama ** (a, b, c), ia bersamaan dengan mencipta (a) indeks lajur tunggal, (a, b ) indeks bersama dan (a, b, c) indeks bersama, jika anda mahu indeks itu berkesan, anda hanya boleh menggunakan tiga kombinasi sudah tentu, kami telah menguji di atas bahawa gabungan a dan c juga boleh digunakan, tetapi sebenarnya hanya indeks a digunakan, dan c tidak Tidak digunakan.

6. Kegagalan indeks

1 Seperti subquery, letakkan % di hadapan

2 atau kenyataan. Apabila hanya satu medan pertanyaan kiri dan kanan daripada atau ialah indeks, indeks itu hanya akan berkuat kuasa apabila kedua-dua medan pertanyaan kiri dan kanan daripada atau ialah indeks; pernyataan (hanya jika terdapat indeks sebelum dan selepas, pengoptimuman SQL diperlukan Elakkan penulisan atau pernyataan

4. Jika varchar tidak disertakan dalam petikan tunggal, ia mungkin ditukar secara automatik kepada jenis int, membatalkan indeks dan menyebabkan imbasan jadual penuh.

7. Mata pengetahuan lain

1 Medan yang perlu diindeks mestilah dalam keadaan mana

2 diindeks kerana ia dibina Pengindeksan mempunyai overhed tertentu Jika jumlah data adalah kecil, tidak perlu membina indeks, dan julat kelajuan adalah perlahan.

3. Indeks bersama mempunyai lebih banyak kelebihan daripada membina indeks pada setiap lajur, kerana lebih banyak indeks dibuat, lebih banyak ruang cakera diduduki, dan semakin perlahan ia akan berlaku semasa mengemas kini data membina indeks berbilang lajur, susunan Ia juga penting untuk ambil perhatian bahawa pengindeksan yang ketat harus diletakkan terlebih dahulu, supaya penyaringan akan menjadi lebih kuat dan lebih cekap.

八、MySQL存储引擎简介

1、InnoDB

支持事务处理，支持外键，支持崩溃修复能力和并发控制。如果需要对事务的完整性要求比较高（比如银行），要求实现并发控制（比如售票），那选择InnoDB有很大的优势。如果需要频繁的更新、删除操作的数据库，也可以选择InnoDB，因为支持事务的提交和回滚。

2、MyISAM

插入速度快，空间和内存使用比较低。如果表主要是用于插入新纪录和读取记录，那么选择MyISAM能实现处理高效率。如果应用的完整性、并发要求比较低，也可以使用。

注意，同一个数据库也可以使用多种存储引擎的表。如果一个表要求比较高的事务处理，可以选择InnoDB。这个数据库中可以将查询要求比较高的表选择MyISAM存储。如果该数据库需要一个用于查询的临时表，可以选择MEMORY存储引擎。

九、索引结构（方法、算法）

在mysql中常用两种索引结构(算法)BTree和Hash，两种算法检索方式不一样，对查询的作用也不一样。

1、Hash

Hash索引的底层实现是由Hash表来实现的，非常适合以 key-value 的形式查询，也就是单个key 查询，或者说是等值查询。

Hash 索引可以比较方便的提供等值查询的场景,由于是一次定位数据，不像BTree索引需 要从根节点到枝节点，最后才能访问到页节点这样多次IO访问，所以检索效率远高于BTree索引。但是对于范围查询的话，就需要进行全表扫描了。

但为什么我们使用BTree比使用Hash多呢？主要Hash本身由于其特殊性，也带来了很多限制和弊端：

• Hash索引仅仅能满足“=”,“IN”,“”查询，不能使用范围查询。

• 联合索引中，Hash索引不能利用部分索引键查询。 对于联合索引中的多个列，Hash是要么全部使用，要么全部不使用，并不支持BTree支持的联合索引的最优前缀，也就是联合索引的前面一个或几个索引键进行查询时，Hash索引无法被利用。

• Hash索引无法避免数据的排序操作 由于Hash索引中存放的是经过Hash计算之后的Hash值，而且Hash值的大小关系并不一定和Hash运算前的键值完全一样，所以数据库无法利用索引的数据来避免任何排序运算。

• Hash索引任何时候都不能避免表扫描 Hash索引是将索引键通过Hash运算之后，将Hash运算结果的Hash值和所对应的行指针信息存放于一个Hash表中，由于不同索引键存在相同Hash值，所以即使满足某个Hash键值的数据的记录条数，也无法从Hash索引中直接完成查询，还是要通过访问表中的实际数据进行比较，并得到相应的结果。

• Hash索引遇到大量Hash值相等的情况后性能并不一定会比BTree高 对于选择性比较低的索引键，如果创建Hash索引，那么将会存在大量记录指针信息存于同一个Hash值相关联。这样要定位某一条记录时就会非常麻烦，会浪费多次表数据访问，而造成整体性能底下。

2、B+ Tree

B+Tree索引是最常用的mysql数据库索引算法，因为它不仅可以被用在=,>,>=,

例如：

select * from user where name like 'jack%'; select * from user where name like 'jac%k%';

如果一通配符开头，或者没有使用常量，则不会使用索引，

例如：

select * from user where name like '%jack'; select * from user where name like simply_name;

3、 B+/-Tree原理

在数据库中，数据量相对较大，多路查找树显然更加适合数据库的应用场景，接下来我们就介绍这两类多路查找树，毕竟作为程序员，心里没点B树怎么能行呢？

B树：B树就是B-树，他有着如下的特性：

• B树不同于二叉树，他们的一个节点可以存储多个关键字和多个子树指针，这就是B+树的特点；

• 一个m阶的B树要求除了根节点以外，所有的非叶子子节点必须要有[m/2,m]个子树；

• 根节点必须只能有两个子树，当然，如果只有根节点一个节点的情况存在；

• B树是一个查找二叉树，这点和二叉查找树很像，他都是越靠前的子树越小，并且，同一个节点内，关键字按照大小排序；

• B树的一个节点要求子树的个数等于关键字的个数+1；

B+树就是B树的plus版

• B+树将所有的查找结果放在叶子节点中，这也就意味着查找B+树，就必须到叶子节点才能返回结果；

• Bilangan kata kunci dalam setiap nod pepohon B adalah sama dengan bilangan penuding subpokok; nod daun pokok B sepadan dengan penunjuk A, dan kuncinya ialah nilai maksimum atau minimum bagi subpokok; nod daun Pokok B hanya menyimpan maklumat Nilai kunci, dengan mengandaikan bahawa setiap blok cakera boleh menyimpan 4 nilai kunci dan maklumat penunjuk, struktur selepas menjadi Pokok B adalah seperti yang ditunjukkan di bawah:

• Biasanya terdapat dua Satu penunjuk menunjuk ke nod akar, satu lagi menunjuk ke nod daun dengan kunci terkecil, dan terdapat struktur cincin rantai antara semua nod daun (iaitu, nod data). Oleh itu, dua operasi carian boleh dilakukan pada B Tree: satu ialah carian julat dan carian halaman untuk kunci utama, dan satu lagi ialah carian rawak bermula dari nod akar.

Mungkin hanya terdapat 22 rekod data dalam contoh di atas, dan kelebihan B Tree tidak dapat dilihat Berikut adalah pengiraan:

Saiz halaman dalam enjin storan InnoDB ialah 16KB, dan jenis kunci utama jadual umum Ia adalah INT (menduduki 4 bait) atau BIGINT (menduduki 8 bait), dan jenis penuding biasanya 4 atau 8 bait, yang bermaksud bahawa satu halaman (nod dalam B Tree) mungkin menyimpan

nilai kunci (kerana ia adalah anggaran, untuk kemudahan pengiraan, nilai K di sini ialah 〖10〗^3).

Dalam erti kata lain, indeks B Tree dengan kedalaman 3 boleh mengekalkan rekod.

Dalam situasi sebenar, setiap nod mungkin tidak diisi sepenuhnya, jadi dalam pangkalan data, ketinggian B Tree biasanya 2-4 lapisan. Enjin storan InnoDB MySQL direka bentuk supaya nod akar bermastautin dalam ingatan, yang bermaksud bahawa hanya 1 hingga 3 operasi I/O cakera diperlukan untuk mencari rekod baris bagi nilai kunci tertentu.

Indeks B Tree dalam pangkalan data boleh dibahagikan kepada indeks berkelompok dan indeks sekunder. Contoh rajah B Tree di atas dilaksanakan dalam pangkalan data sebagai indeks berkelompok Nod daun dalam B Tree indeks berkelompok menyimpan data rekod baris keseluruhan jadual. Perbezaan antara indeks tambahan dan indeks berkelompok ialah nod daun indeks tambahan tidak mengandungi semua data rekod baris, tetapi kunci indeks berkelompok yang menyimpan data baris yang sepadan, iaitu kunci utama. Apabila menanyakan data melalui indeks tambahan, enjin storan InnoDB akan merentasi indeks tambahan untuk mencari kunci utama, dan kemudian mencari data rekod baris lengkap dalam indeks berkelompok melalui kunci utama.

16KB/(8B 8B)=1KPembelajaran yang disyorkan:
tutorial video mysql10^3 * 10^3 * 10^3 = 10亿

Atas ialah kandungan terperinci Indeks lajur tunggal MySQL dan ringkasan indeks bersama. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!