火影推薦程式連載71-「Spring Boot 2.4 新特性」一鍵構建Docker映象

阿新 • • 發佈：2020-11-18

為什麼要使用索引？

通過建立唯一性索引，可以保證資料庫表中每一行資料的唯一性。
可以大大加快資料的檢索速度（大大減少的檢索的資料量）, 這也是建立索引的最主要的原因。
幫助伺服器避免排序和臨時表。
將隨機IO變為順序IO
可以加速表和表之間的連線，特別是在實現資料的參考完整性方面特別有意義。

索引這麼多優點，為什麼不對錶中的每一個列建立一個索引呢？

當對錶中的資料進行增加、刪除和修改的時候，索引也要動態的維護，這樣就降低了資料的維護速度。
索引需要佔物理空間，除了資料表佔資料空間之外，每一個索引還要佔一定的物理空間，如果要建立聚簇索引，那麼需要的空間就會更大。
建立索引和維護索引要耗費時間，這種時間隨著資料量的增加而增加。

使用索引的注意事項？

在經常需要搜尋的列上，可以加快搜索的速度；
在經常使用在WHERE子句中的列上面建立索引，加快條件的判斷速度。
在經常需要排序的列上創建索引，因為索引已經排序，這樣查詢可以利用索引的排序，加快排序查詢時間；
對於中到大型表索引都是非常有效的，但是特大型表的話維護開銷會很大，不適合建索引
在經常用在連線的列上，這些列主要是一些外來鍵，可以加快連線的速度；
避免 where 子句中對欄位施加函式，這會造成無法命中索引。
在使用InnoDB時使用與業務無關的自增主鍵作為主鍵，即使用邏輯主鍵，而不要使用業務主鍵。
~~將打算加索引的列設定為 NOT NULL ，否則將導致引擎放棄使用索引而進行全表掃描。~~

訂正，來自。將某一列設定為default null，where 是可以走索引，另外索引列是否設定 null 是不影響效能的。 但是，還是不建議列上允許為空。最好限制not null，因為null需要更多的儲存空間並且null值無法參與某些運算。

《高效能MySQL》第四章如是說：And, in case you’re wondering, allowing NULL values in the index really doesn’t impact performance 。NULL 值的索引查詢流程參考： ,相關閱讀：。
刪除長期未使用的索引，不用的索引的存在會造成不必要的效能損耗 MySQL 5.7 可以通過查詢 sys 庫的 chema_unused_indexes 檢視來查詢哪些索引從未被使用
在使用 limit offset 查詢緩慢時，可以藉助索引來提高效能

Mysql索引主要使用的兩種資料結構

雜湊索引

對於雜湊索引來說，底層的資料結構就是雜湊表，因此在絕大多數需求為單條記錄查詢的時候，可以選擇雜湊索引，查詢效能最快；其餘大部分場景，建議選擇BTree索引。

BTree索引

MyISAM和InnoDB實現BTree索引方式的區別

MyISAM

B+Tree葉節點的data域存放的是資料記錄的地址。在索引檢索的時候，首先按照B+Tree搜尋演算法搜尋索引，如果指定的Key存在，則取出其 data 域的值，然後以 data 域的值為地址讀取相應的資料記錄。這被稱為“非聚簇索引”。

InnoDB

其資料檔案本身就是索引檔案。相比MyISAM，索引檔案和資料檔案是分離的，其表資料檔案本身就是按B+Tree組織的一個索引結構，樹的葉節點data域儲存了完整的資料記錄。這個索引的key是資料表的主鍵，因此InnoDB表資料檔案本身就是主索引。這被稱為“聚簇索引（或聚集索引）”，而其餘的索引都作為輔助索引，輔助索引的data域儲存相應記錄主鍵的值而不是地址，這也是和MyISAM不同的地方。在根據主索引搜尋時，直接找到key所在的節點即可取出資料；在根據輔助索引查詢時，則需要先取出主鍵的值，在走一遍主索引。因此，在設計表的時候，不建議使用過長的欄位作為主鍵，也不建議使用非單調的欄位作為主鍵，這樣會造成主索引頻繁分裂。 PS：整理自《Java工程師修煉之道》

覆蓋索引介紹

什麼是覆蓋索引

如果一個索引包含（或者說覆蓋）所有需要查詢的欄位的值，我們就稱之為“覆蓋索引”。我們知道InnoDB儲存引擎中，如果不是主鍵索引，葉子節點儲存的是主鍵+列值。最終還是要“回表”，也就是要通過主鍵再查詢一次。這樣就會比較慢覆蓋索引就是把要查詢出的列和索引是對應的，不做回表操作！

覆蓋索引使用例項

現在我建立了索引(username,age)，我們執行下面的 sql 語句

select username , age from user where username = 'Java' and age = 22

在查詢資料的時候：要查詢出的列在葉子節點都存在！所以，就不用回表。

選擇索引和編寫利用這些索引的查詢的3個原則

單行訪問是很慢的。特別是在機械硬碟儲存中(SSD的隨機I/O要快很多，不過這一點仍然成立）。如果伺服器從儲存中讀取一個數據塊只是為了獲取其中一行，那麼就浪費了很多工作。最好讀取的塊中能包含儘可能多所需要的行。使用索引可以建立位置引，用以提升效率。
按順序訪問範圍資料是很快的，這有兩個原因。第一，順序 I/O 不需要多次磁碟尋道，所以比隨機I/O要快很多（特別是對機械硬碟）。第二，如果伺服器能夠按需要順序讀取資料，那麼就不再需要額外的排序操作，並且GROUPBY查詢也無須再做排序和將行按組進行聚合計算了。
索引覆蓋查詢是很快的。如果一個索引包含了查詢需要的所有列，那麼儲存引擎就不需要再回表查詢行。這避免了大量的單行訪問，而上面的第1點已經寫明單行訪問是很慢的。

為什麼索引能提高查詢速度

以下內容整理自：掘金
地址：
作者：Java3y

先從 MySQL 的基本儲存結構說起

MySQL的基本儲存結構是頁(記錄都存在頁裡邊)：

各個資料頁可以組成一個雙向連結串列
每個資料頁中的記錄又可以組成一個單向連結串列
- 每個資料頁都會為儲存在它裡邊兒的記錄生成一個頁目錄，在通過主鍵查詢某條記錄的時候可以在頁目錄中使用二分法快速定位到對應的槽，然後再遍歷該槽對應分組中的記錄即可快速找到指定的記錄
- 以其他列(非主鍵)作為搜尋條件：只能從最小記錄開始依次遍歷單鏈表中的每條記錄。

所以說，如果我們寫select * from user where indexname = 'xxx'這樣沒有進行任何優化的sql語句，預設會這樣做：

定位到記錄所在的頁：需要遍歷雙向連結串列，找到所在的頁
從所在的頁內中查詢相應的記錄：由於不是根據主鍵查詢，只能遍歷所在頁的單鏈表了

很明顯，在資料量很大的情況下這樣查詢會很慢！這樣的時間複雜度為O（n）。

使用索引之後

索引做了些什麼可以讓我們查詢加快速度呢？其實就是將無序的資料變成有序(相對)：

要找到id為8的記錄簡要步驟：

很明顯的是：沒有用索引我們是需要遍歷雙向連結串列來定位對應的頁，現在通過 “目錄” 就可以很快地定位到對應的頁上了！（二分查詢，時間複雜度近似為O(logn)）

其實底層結構就是B+樹，B+樹作為樹的一種實現，能夠讓我們很快地查找出對應的記錄。

關於索引其他重要的內容補充

以下內容整理自：《Java工程師修煉之道》

最左字首原則

MySQL中的索引可以以一定順序引用多列，這種索引叫作聯合索引。如User表的name和city加聯合索引就是(name,city)，而最左字首原則指的是，如果查詢的時候查詢條件精確匹配索引的左邊連續一列或幾列，則此列就可以被用到。如下：

select * from user where name=xx and city=xx ; --可以命中索引
select * from user where name=xx ; -- 可以命中索引
select * from user where city=xx ;  --無法命中索引

這裡需要注意的是，查詢的時候如果兩個條件都用上了，但是順序不同，如 city= xx and name ＝xx，那麼現在的查詢引擎會自動優化為匹配聯合索引的順序，這樣是能夠命中索引的。

由於最左字首原則，在建立聯合索引時，索引欄位的順序需要考慮欄位值去重之後的個數，較多的放前面。ORDER BY子句也遵循此規則。

注意避免冗餘索引

冗餘索引指的是索引的功能相同，能夠命中就肯定能命中，那麼就是冗餘索引如（name,city ）和（name ）這兩個索引就是冗餘索引，能夠命中後者的查詢肯定是能夠命中前者的在大多數情況下，都應該儘量擴充套件已有的索引而不是建立新索引。

MySQL 5.7 版本後，可以通過查詢 sys 庫的 schema_redundant_indexes 表來檢視冗餘索引

Mysql如何為表字段新增索引？？？

1.新增PRIMARY KEY（主鍵索引）

ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` )

2.新增UNIQUE(唯一索引)

ALTER TABLE `table_name` ADD UNIQUE ( `column` )

3.新增INDEX(普通索引)

ALTER TABLE `table_name` ADD INDEX index_name ( `column` )

4.新增FULLTEXT(全文索引)

ALTER TABLE `table_name` ADD FULLTEXT ( `column`)

5.新增多列索引

ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` )

作者：Snailclimb
連結：
來源：github