MySql—索引原理
?
一、數(shù)據(jù)庫索引
很大一部份程序員對索引的了解僅限于到“加索引能使查詢變快”這個概念為止,但有沒有考慮過索引為什么能使查詢變快呢?索引是使用B+樹(二叉樹)實現(xiàn)的數(shù)據(jù)結構。
上圖中左邊是數(shù)據(jù)庫中的數(shù)據(jù)表,有col1和col2兩個字段,一共有15條記錄;右邊是以col2列為索引列的B_TREE索引,每個節(jié)點包含索引的鍵值和對應數(shù)據(jù)表地址的指針,這樣就可以都過B_TREE在O(logn)的時間復雜度內獲取相應的數(shù)據(jù),這樣明顯地加快了檢索的速度。再來思考下以下幾個問題:
1.數(shù)據(jù)表為什么會使用主鍵?
一個沒加主鍵的表,它的數(shù)據(jù)無序的放置在磁盤存儲器上,一行一行的排列的很整齊。一個加了主鍵的表,并不能被稱之為「表」。如果給表上了主鍵,那么表在磁盤上的存儲結構就由整齊排列的結構轉變成了樹狀結構,并且是「平衡樹」結構,換句話說,就是整個表就變成了一個索引。 這就是為什么一個表只能有一個主鍵,一個表只能有一個「聚集索引」,因為主鍵的作用就是把「表」的數(shù)據(jù)格式轉換成「索引(平衡樹)」的格式放置。
給表中多個字段加上常規(guī)的索引,那么就會出現(xiàn)多個獨立的索引結構.字段中的數(shù)據(jù)就會被復制一份出來,用于生成索引,葉子節(jié)點是主鍵ID,這也就是非聚集索引.,下面就是一個主鍵和三個常規(guī)索引的結構。通過其他索引字段去查,那么葉子節(jié)點是主鍵ID,然后再去根據(jù)主鍵查,聚集索引(主鍵)是通往真實數(shù)據(jù)所在的唯一路徑
2.使用索引后會使插入、修改、刪除變慢?
這個很好理解,使用索引后,會生成新的二叉樹,插入速度自然變慢
二、Myisam引擎(非聚集索引)
若以這個引擎創(chuàng)建數(shù)據(jù)庫表Create table user (…..),它實際是生成三個文件:user.myi索引文件、user.myd數(shù)據(jù)文件、user.frm數(shù)據(jù)結構類型。如下圖:當我們執(zhí)行 ?select?* from user where id = 1的時候,它的執(zhí)行流程。
三、Innodb引擎(聚集索引)
若以這個引擎創(chuàng)建數(shù)據(jù)庫表Create table user (…..),它實際是生成兩個文件:user.ibd ??索引文件、user.frm數(shù)據(jù)結構類型。因為innodb引擎創(chuàng)建表默認就是以主鍵為索引,所以不需要myi文件。下圖為innodb表的結構圖:很顯然它與myisam最大的區(qū)別是將整條數(shù)據(jù)存在葉子節(jié)點,而不是地址。(葉子節(jié)點存的是主鍵索引和數(shù)據(jù)信息)若此時,你在其他列創(chuàng)建索引例如name,它就會另外創(chuàng)建一個以name為索引的索引樹,(葉子節(jié)點存的是索引和主鍵索引)。你在執(zhí)行select * from user where name = ‘吳磊’,他的執(zhí)行過程如下:
四、MyISAM引擎和InnoDB引擎的區(qū)別
- MyISAM:支持全文索引;不支持事務;它是表級鎖;會保存表的具體行數(shù).
- InnoDB:5.6以后才有全文索引;支持事務;它是行級鎖;不會保存表的具體行數(shù).
一般:不用事務的時候,count計算多的時候適合myisam引擎。對可靠性要求高就是用innodby引擎。推薦用InnoDB引擎.加了索引之后能夠大幅度的提高查詢速度,但是索引也不是越多越好,一方面它會占用存儲空間,另一方面它會使得寫操作變得很慢。通常我們對查詢次數(shù)比較頻繁,值比較多的列才建索引。例如:select * from user where sex = "女", 這個就不需要建立索引,因為性別一共就兩個值,查詢本身就是比較快的。select * from user where user_id = 1995 ,這個就需要建立索引,因為user_id的值是非常多的。
參考文章:
了解數(shù)據(jù)庫索引及其原理
MySQL為什么要給表加上主鍵
?
總結
以上是生活随笔為你收集整理的MySql—索引原理的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Redis—主从复制
- 下一篇: MySql—锁机制原理