《Java後端知識體系》系列之MySQL

每天都覺得時間不夠用，每天都要爭分奪秒的工作，吃飯，學習，整理知識點！爲什麼一天不是36小時！！！

MySQL：

• 存儲引擎：

  • 分類：
    • MyISAM：在5.5版本之前，MyISAM是MySQL的默認存儲引擎，該存儲引擎併發性差，不支持事務，所以使用場景比較少，主要特點爲：
      • （1）不支持事務；
      • （2）不支持外鍵，如果強行增加外鍵，不會提示錯誤，只是外鍵不其作用；
      • （3）對數據的查詢緩存只會緩存索引，不會像InnoDB一樣緩存數據，而且是利用操作系統本身的緩存；
      • （4）默認的鎖粒度爲表級鎖，所以併發度很差，加鎖快，鎖衝突較少，所以不太容易發生死鎖；
      • （5）支持全文索引（MySQL5.6之後，InnoDB存儲引擎也對全文索引做了支持），但是MySQL的全文索引基本不會使用，對於全文索引，現在有其他成熟的解決方案，比如：ElasticSearch，Solr，Sphinx等。
      • （6）數據庫所在主機如果宕機，MyISAM的數據文件容易損壞，而且難恢復；
    • InnoDB：從MySQL5.5版本之後，MySQL的默認內置存儲引擎已經是InnoDB了，他的主要特點有：
      • （1）災難恢復性比較好；
      • （2）支持事務。默認的事務隔離級別爲可重複度，通過MVCC（併發版本控制）來實現的。
      • （3）使用的鎖粒度爲行級鎖，可以支持更高的併發；
      • （4）支持外鍵；
      • （5）配合一些熱備工具可以支持在線熱備份；
      • （6）在InnoDB中存在着緩衝管理，通過緩衝池，將索引和數據全部緩存起來，加快查詢的速度；
      • （7）對於InnoDB類型的表，其數據的物理組織形式是聚簇表。所有的數據按照主鍵來組織。數據和索引放在一塊，都位於B+數的葉子節點上；
  • 總結：
    • 1、由於鎖粒度的不同，InnoDB比MyISAM支持更高的併發；
    • 2、InnoDB爲行級鎖，MyISAM爲表級鎖，所以InnoDB相對於MyISAM來說，更容易發生死鎖，鎖衝突的概率更大，而且上鎖的開銷也更大，因爲需要爲每一行加鎖；
    • 3、在備份容災上，InnoDB支持在線熱備，有很成熟的在線熱備解決方案；
    • 4、查詢性能上，MyISAM的查詢效率高於InnoDB，因爲InnoDB在查詢過程中，是需要維護數據緩存，而且查詢過程是先定位到行所在的數據塊，然後在從數據塊中定位到要查找的行；而MyISAM可以直接定位到數據所在的內存地址，可以直接找到數據；
    • 5、SELECT COUNT(*)語句，如果行數在千萬級別以上，MyISAM可以快速查出，而InnoDB查詢的特別慢，因爲MyISAM將行數單獨存儲了，而InnoDB需要朱行去統計行數；所以如果使用InnoDB，而且需要查詢行數，則需要對行數進行特殊處理，如：離線查詢並緩存；
    • 6、MyISAM的表結構文件包括：.frm(表結構定義),.MYI(索引),.MYD(數據)；而InnoDB的表數據文件爲:.ibd和.frm(表結構定義)；
• 如何選擇合適的存儲引擎
  • 1、使用場景是否需要事務支持；
  • 2、是否需要支持高併發，InnoDB的併發度遠高於MyISAM；
  • 3、是否需要支持外鍵；
  • 4、是否需要支持在線熱備；
  • 5、高效緩衝數據，InnoDB對數據和索引都做了緩衝，而MyISAM只緩衝了索引；
  • 6、索引，不同存儲引擎的索引並不太一樣；

• 事務：

  • 原子性：整個事務的所有操作，要麼全部完成，要麼全部不完成，事務執行過程中發生錯誤，會被回滾到事務開始之前
  • 一致性：事務開始之前和事務結束之後，數據庫的完整性約束沒有被破壞
  • 隔離性：併發執行的事務彼此無法看到對方的中間狀態
  • 持久性：事務完成之後所有的改動都會被持久化。
  • 事務的實現流程：
    • 通過預寫日誌的方式實現，redo和undo時實現數據庫事務的基礎
    • redo日誌用來在斷電或者數據庫崩潰等狀況發生時重新刷數據，把redo日誌的數據刷新到數據庫中，保證事務的持久性
    • undo日誌在事務操作失敗時撤銷對數據庫的操作，保證事務的原子性。

• 隔離級別：

  • 讀未提交：可以讀取到其它會話未提交的數據
  • 讀已提交：允許不可重複讀，但不允許髒讀。提交後其它會話可以看到提交的數據。
  • 可串行化：事務只能一個接一個執行，但不能併發執行，事務隔離級別最高。
  • 可重複度：事務A在讀到一條數據之後，此時事務B對該數據進行了修改並提交，那麼事務A再讀該數據，讀到的還是原來的內容

• 索引：

  • 索引的解釋：索引是數據庫管理系統中的一個排序的數據結構，它是對數據表中一列或多列的數據進行排序，以此來加快訪問數據表數據的速度。索引可以理解爲書的目錄，通過目錄可以快速找到想看的內容，索引可以快速找到我們想要的數據。
  • 場景：在項目中當我們查詢數據庫的數據時，數據少時對我們的查詢沒有影響，但是若數據量很大時，就會很嚴重的影響查詢效率，因此爲了提高查詢效率我們引入了索引，通過索引來提高我們的查詢效率。
  • 數據結構：索引的數據結構使用的是B+Tree，B+Tree的一些特徵使它適合做索引的數據結構：首先B+Tree的所有非葉子節點只保存關鍵字不保存數據，所有的數據保存在葉子節點；2，葉子節點中使用指針來指向下一個數據，所以適合範圍查找；3、所有的數據都存在葉子節點，因此所有關鍵字查詢的路徑都是相同的，即每個數據的查詢效率相當。想要了解更多的關於樹的知識，可以看看我的另一篇文章。
    
  • 類型：
    • 普通索引：由關鍵字定義的索引加快對數據的訪問速度
    • 唯一索引：普通索引會包含重複值，唯一索引不會但是可以爲null，目的使加快訪問速度避免數據出現重複
    • 主鍵索引：主鍵字段創建的索引，一張表只能有一個主鍵索引
    • 組合索引：多個列組成的索引，用於組合搜索
    • 全文索引：對文本的內容進行分詞然後搜索。
  • 使用策略：
    • 主鍵自動建立唯一索引
    • 經常作爲查詢條件在where或者order by語句中出現的列建立索引
    • 經常用於聚合函數的列需要建立索引
    • 經常增刪改的列不要建立索引
    • 數據少不要建立索引
    • 組合索引中進行order by時要遵循組合索引列的順序
    • 避免使用索引時在where中使用各種SQL函數

今天也是會敲代碼的湯姆貓！