數據庫基礎知識（必讀）

參考文章：

Cyc2018-數據庫系統原理

mysql索引的新手入門詳解

多個單列索引和聯合索引的區別詳解

MySQL體系架構

MySQL體系結構

MySQL體系結構

【MySQL】漫談MySQL體系結構

MySQL面試題(六)數據庫的分庫分表原理詳解

MySQL數據庫之互聯網常用分庫分表方案

事務

1、什么是數據庫事務？事務的屬性？

事務指單個邏輯單元執行的一系列操作，要么都執行，要么都不執行。

一個邏輯單元要成為事務，必須滿足ACID的屬性，即原子性、一致性、隔離性、持久性

原子性：

一件事情會有多個動作，必須都執行或都不執行。 事務是最小的執行單位，不可分割

一致性：

數據庫的數據要在事務前后保持一致。

隔離性：

對同一個表並發進行多個事務，事務間相互隔離。

持久性：

一旦事情commit，不可更改，持久生效。

AUTOCOMMIT

MySQL 默認采用自動提交模式。也就是說，如果不顯式使用 START TRANSACTION 語句來開始一個事務，那么每個 查詢都會被當做一個事務自動提交。

2、並發事務帶來哪些問題?

臟讀：

一個事務讀取到被另一個事務修改當還未提交的數據，依據“臟數據”所做的操作可能是不正確的。

丟失修改：

一個事務修改了被另一個事務修改當還未提交的數據，先提交的事務的修改就會丟失

不可重復讀：

指在一個事務內多次讀同一數據。在這個事務還沒有結束時，另一個事務修改了該數據。這就發生了在一個事務內兩次讀到的數據是不一樣的情況，因此稱為不可重復讀。

幻讀：

一個事務讀取一個范圍內的數據，另一個事務向這個范圍內插入了一些數據，在隨后的查詢中，第一個事務（T1）就會發現多了一些原本不存在的記錄，就好像發生了幻覺一樣，所以稱為幻讀。

不可重復讀和幻讀區別：

不可重復讀的重點是對單條記錄的修改，比如多次讀取一條記錄發現其中某些列的值被修改；幻讀的重點在於對多條記錄的新增或者刪除，比如多次讀取一個范圍的記錄發現記錄增多或減少了。

產生並發不一致性問題主要原因是破壞了事務的隔離性，解決方法是通過並發控制來保證隔離性。並發控制可以通過加鎖來實現，但是加鎖操作需要用戶自己控制，相當復雜。數據庫管理系統提供了事務的隔離級別，讓用戶以一種更輕松的方式處理並發一致性問題。

 

3、事務隔離級別有哪些? MySQL的默認隔離級別是?

SQL 標准定義了四個隔離級別：

READ-UNCOMMITTED(未提交讀)： 

最低的隔離級別，允許讀取尚未提交的數據變更，可能會導致臟讀、幻讀或不可重復讀。

READ-COMMITTED(提交讀)： 

允許讀取並發事務已經提交的數據， 可以阻止臟讀，但是幻讀或不可重復讀仍有可能發生。

REPEATABLE-READ(可重復讀)：

對同一字段的多次讀取結果都是一致的，除非數據是被本身事務自己所修改， 可以阻止臟讀和不可重復讀，但幻讀仍有可能發生。

SERIALIZABLE(可串行化)：

最高的隔離級別，完全服從ACID的隔離級別。所有的事務依次逐個執行，這樣事務之間就完全不可能產生干擾，也就是說， 該級別可以防止臟讀、不可重復讀以及幻讀。

4、事務隔離級別的RR和RC是怎么實現的

《 MySQL MVCC 和 鎖機制 》

相關語法

1、建表的原則（三大范式）

第一范式（1NF）

    屬性不可分

第二范式

符合第一范式，且非主屬性完全依賴於碼，消除了部分依賴 --> 非主屬性不能完全依賴於碼的一部分，如（A, B)是碼，非主屬性 C 依賴於 （A, B), 但是如果同時 A -> C, 即 C 又依賴於 A ,那么就存在部分依賴，這時 C 屬性應該從表中脫離出來，與 A共同 成為一張表

第三范式

符合第二范式，且消除傳遞依賴，也就是每個非主屬性都不傳遞依賴於候選鍵，即如果存在 A -> B -> C, 這時就存在傳遞依賴，C 應該從表中脫離出來 與 B 共同形成一張表。

BC范式

符合3NF，並且，消除每一個屬性對候選鍵的傳遞依賴

2、MySQL外連接知道嗎？左外連接和右外連接是什么，有什么區別？什么是內連接，完全連接

外連接分為左外連接和右外連接

左(外)連接，左表(a_table)的記錄將會全部表示出來，而右表(b_table)只會顯示符合搜索條件的記錄。右表記錄不足的地方均為NULL

與左(外)連接相反，右(外)連接，左表(a_table)只會顯示符合搜索條件的記錄，而右表(b_table)的記錄將會全部表示出來。左表記錄不足的地方均為NULL。

完全連接就是左表和右表都是展示所有記錄

內連接是左右表都只顯示符合搜索條件的記錄

性能優化

1、mysql性能優化

Mysql高性能優化規范建議

MySQL 索引

索引是在存儲引擎層實現的，而不是在服務器層實現的，所以不同存儲引擎具有不同的索引類型和實現。

 

索引的優點

1.  通過建立索引樹，從上往下搜索索引樹大大減少了服務器需要掃描的數據行數。

2. 幫助服務器避免進行排序和分組，以及避免創建臨時表（B+Tree 索引是有序的，可以用於 ORDER BY 和  GROUP BY 操作。臨時表主要是在排序和分組過程中創建，不需要排序和分組，也就不需要創建臨時表）。

3. 將隨機 I/O 變為順序 I/O（B+Tree 索引是有序的，會將相鄰的數據都存儲在一起）。

為什么不對表的每個列創建一個索引

1. 索引會占內存空間

2. 維護索引和修改索引有一定的開銷

索引選取類型

    1、越小的數據類型通常更好：越小的數據類型通常在磁盤、內存和CPU緩存中都需要更少的空間，處理起來更快。

    2、簡單的數據類型更好：整型數據比起字符，處理開銷更小，因為字符串的比較更復雜。

    3、盡量避免NULL：應該指定列為NOT nuLL,在MySQL中， 含有空值的列很難進行查詢優化，因為它們使得索引、索引的統計信息以及比較運算更加復雜

什么場景不適合創建索引

     第一，對於那些在查詢中很少使用或者參考的列不應該創建索引。這是因 為，既然這些列很少使用到，因此有索引或者無索引，並不能提高查詢速度。相反，由於增加了索引，反而降低了系統的維護速度和增大了空間需求。

     第二，對於那 些只有很少數據值的列也不應該增加索引。因為本來結果集合就是相當於全表查詢了，所以沒有必要。這是因為，由於這些列的取值很少，例如人事表的性別列，在查詢的結果中，結果集的數據行占了表中數據行的很大比 例，即需要在表中搜索的數據行的比例很大。增加索引，並不能明顯加快檢索速度。

      第三，對於那些定義為text, image和bit數據類型的列不應該增加索引。這是因為，這些列的數據量要么相當大，要么取值很少。

     第四，當修改開銷遠遠大於檢索開銷時，不應該創建索 引。這是因為，修改性能和檢索性能是互相矛盾的。當增加索引時，會提高檢索性能，但是會降低修改性能。當減少索引時，會提高修改性能，降低檢索性能。因 此，當修改性能遠遠大於檢索性能時，不應該創建索引。

      第五，不會出現在where條件中的字段不該建立索引。

什么樣的字段適合創建索引

1、表的主鍵、外鍵必須有索引；外鍵是唯一的，而且經常會用來查詢

2、數據量超過300的表應該有索引；

3、經常與其他表進行連接的表，在連接字段上應該建立索引；經常連接查詢，需要有索引

4、經常出現在Where子句中的字段，加快判斷速度，特別是大表的字段，應該建立索引，建立索引，一般用在select ……where f1 and f2 ，我們在f1或者f2上建立索引是沒用的。只有兩個使用聯合索引才能有用

5、經常用到排序的列上，因為索引已經排序。

6、經常用在范圍內搜索的列上創建索引，因為索引已經排序了，其指定的范圍是連續的

索引失效：

所謂的索引失效指的是：假如or連接的倆個查詢條件字段中有一個沒有單列索引的話,引擎會放棄索引而產生全表掃描。

 

索引物理分類

 

聚簇索引和非聚簇索引

所謂聚集和非聚集：非聚集索引葉子頁包含一個指向表中的記錄的指針地址，記錄的物理順序和索引的順序不一致；聚集索引則數據行和鍵值一起保存在葉子頁  而且記錄的排列順序與索引的排列順序一致。

由於InnoDB正式按照 聚集索引的結構來存儲表的，聚簇索引的索引是主鍵，所以只能故一張表只能有一個聚簇索引。輔助索引的存在不影響聚簇索引中數據的組織，所以一張表可以有多個輔助索引

InnoDB 的主鍵索引是 聚簇索引， 輔助索引是 非聚簇索引，葉子結點存儲的的是主鍵和關鍵字。

MyISAM 的主鍵索引和輔助索引都是 非聚簇索引。

聚簇索引的優缺點

優點：

1.數據訪問更快，因為聚簇索引將索引和數據保存在同一個B+樹中，因此從聚簇索引中獲取數據比非聚簇索引更快，

2.  聚簇索引對於主鍵的排序查找和范圍查找速度非常快

缺點：

   1.  插入速度嚴重依賴於插入順序，按照主鍵的順序插入是最快的方式，否則將會出現頁分裂，嚴重影響性能。因此，對於InnoDB表，我們一般都會定義一個自增的ID列為主鍵

   2.  更新主鍵的代價很高，因為將會導致被更新的行移動。因此，對於InnoDB表，我們一般定義主鍵為不可更新。

   3.二級索引訪問需要兩次索引查找，第一次找到主鍵值，第二次根據主鍵值找到行數據。

索引邏輯分類

mysql的索引分為單列索引(主鍵索引，唯一索引，普通索引)和組合索引。
單列索引:一個索引只包含一個列，一個表可以有多個單列索引。
組合索引:一個組合索引包含兩個或兩個以上的列，

 

前綴索引

對於列的值較長，比如BLOB、TEXT、VARCHAR，就必須建立前綴索引，即將值的前一部分作為索引。這樣既可以節約空間，又可以提高查詢效率。但無法使用前綴索引做 ORDER BY 和 GROUP BY，也無法使用前綴索引做覆蓋掃描。

覆蓋索引

索引的字段正好是覆蓋查詢語句[select子句]與查詢條件[Where子句]中所涉及的字段。能通過檢索索引就可以讀取想要的數據，那就不需要再到數據表中讀取行了

覆蓋索引的優化及限制

 覆蓋索引是一種非常強大的工具，能大大提高查詢性能，只需要讀取索引而不需要讀取數據，有以下優點：

 1、索引項通常比記錄要小，所以MySQL訪問更少的數據。

 2、索引都按值得大小存儲，相對於隨機訪問記錄，需要更少的I/O。

 3、數據引擎能更好的緩存索引，比如MyISAM只緩存索引。

 4、覆蓋索引對InnoDB尤其有用，因為InnoDB使用聚集索引組織數據，如果二級索引包含查詢所需的數據，就不再需要在聚集索引中查找了。

 限制：

 1、覆蓋索引也並不適用於任意的索引類型，索引必須存儲列的值。

 2、Hash和full-text索引不存儲值，因此MySQL只能使用BTree。

 3、不同的存儲引擎實現覆蓋索引都是不同的，並不是所有的存儲引擎都支持覆蓋索引。

 4、如果要使用覆蓋索引，一定要注意SELECT列表值取出需要的列，不可以SELECT * ，因為如果將所有字段一起做索引會導致索引文件過大，查詢性能下降。

 

最左前綴原則：

顧名思義是最左優先，以最左邊的為起點任何連續的索引都能匹配上，
注：如果第一個字段是范圍查詢需要單獨建一個索引
注：在創建聯合索引時，要根據業務需求，where子句中使用最頻繁的一列放在最左邊。這樣的話擴展性較好，比如 userid 經常需要作為查詢條件，而 mobile 不常常用，則需要把 userid 放在聯合索引的第一位置，即最左邊

同時存在聯合索引和單列索引（字段有重復的），這個時候查詢mysql會怎么用索引呢？

這個涉及到mysql本身的查詢優化器策略了，當一個表有多條索引可走時, Mysql 根據查詢語句的成本來選擇走哪條索引；

聯合索引本質：

 

當創建(a,b,c)聯合索引時，相當於創建了(a)單列索引，(a,b)聯合索引以及 (a,b,c)聯合索引，想要索引生效的話,只能使用 a和a,b和a,b,c三種組合；當然，我們上面測試過，a,c組合也可以，但實際上只用到了a的索引，c並沒有用到！

通俗理解：

利用索引中的附加列，您可以縮小搜索的范圍，但使用一個具有兩列的索引 不同於使用兩個單獨的索引。復合索引的結構與電話簿類似，人名由姓和名構成，電話簿首先按姓氏對進行排序，然后按名字對有相同姓氏的人進行排序。如果您知道姓，電話簿將非常有用；如果您知道姓和名，電話簿則更為有用，但如果您只知道名不姓，電話簿將沒有用處。

所以說創建復合索引時，應該仔細考慮列的順序。對索引中的所有列執行搜索或僅對前幾列執行搜索時，復合索引非常有用；僅對后面的任意列執行搜索時，復合索引則沒有用處。

復合索引與單列索引的比較：

1. 如果表中大多數都是單條件查詢，那用單列索引更划得來

2. 有多條件聯合查詢時最好建聯合索引，多個單列索引在多條件查詢時優化器會選擇最優索引策略，可能只用一個索引，也可能將多個索引全用上！ 但多個單列索引底層會建立多個B+索引樹，比較占用空間，也會浪費一定搜索效率，

其他知識點：

 

1、需要加索引的字段，要在where條件中
2、數據量少的字段不需要加索引；因為建索引有一定開銷，如果數據量小則沒必要建索引（速度反而慢）
3、避免在where子句中使用or來連接條件,因為如果倆個字段中有一個沒有索引的話,引擎會放棄索引而產生全表掃描
4、聯合索引比對每個列分別建索引更有優勢，因為索引建立得越多就越占磁盤空間，在更新數據的時候速度會更慢。另外建立多列索引時，順序也是需要注意的，應該將嚴格的索引放在前面，這樣篩選的力度會更大，效率更高。

索引的底層實現

btree、b+tree

1. B+Tree 索引

是大多數 MySQL 存儲引擎的默認索引類型。

因為不再需要進行全表掃描，只需要對樹進行搜索即可，所以查找速度快很多。

因為 B+ Tree 的有序性，所以除了用於查找，還可以用於排序和分組。

可以指定多個列作為索引列，多個索引列共同組成鍵。

適用於全鍵值、鍵值范圍和鍵前綴查找，其中鍵前綴查找只適用於最左前綴查找。如果不是按照索引列的順序進行查找，則無法使用索引。

InnoDB 的 B+Tree 索引分為主索引和輔助索引。主索引的葉子節點 data 域記錄着完整的數據記錄，這種索引方式被稱為聚簇索引。因為無法把數據行存放在兩個不同的地方，所以一個表只能有一個聚簇索引。

輔助索引的葉子節點的 data 域記錄着主鍵的值，因此在使用輔助索引進行查找時，需要先查找到主鍵值，然后再到

主索引中進行查找。

2. 哈希索引

哈希索引能以 O(1) 時間進行查找，但是失去了有序性：

無法用於排序與分組；

只支持精確查找，無法用於部分查找和范圍查找。

InnoDB 存儲引擎有一個特殊的功能叫“自適應哈希索引”，當某個索引值被使用的非常頻繁時，會在 B+Tree 索引之

上再創建一個哈希索引，這樣就讓 B+Tree 索引具有哈希索引的一些優點，比如快速的哈希查找。

3、BST（二叉查找樹）

  1.vs二分查找，BST在左右子樹節點個數差不多時，查找性能逼近二分查找，但在增刪節點時，BST需要的內存比二分查找少。2.缺點：平衡性差，動態增刪節點可能導致退化為鏈表，查找效率降低。
3.4AVL樹vsRBtree: avl樹是嚴格平衡樹，而rbtree是弱平衡樹，都是通過旋轉來保持平衡，而在增刪節點時，嚴格平衡樹旋轉的次數比弱平衡旋轉的次數多，當搜索節點的次數遠遠大於增刪節點的次數時，旋轉AVL樹，當搜索節點的次數與增刪節點的次數差不多時選擇RBtree效率高。

4、磁盤讀取及預讀的過程及時間消耗？

定位柱面時間（最長）、旋轉至扇區時間、讀寫扇區時間

5、btree定義？

1.每個節點最多有 m 個子樹
2.若根不是葉子結點，則根節點至少有兩個子樹
3.分支節點至少擁有m/2棵子樹（除根和葉子）
4.所有葉子節點都在同一層， 這些葉子結點不存儲有效的信息

5. 每個節點最多可以有m-1個 key 並且升序排列， 相同數量的 key 在btree中生成的節點要遠遠小於二叉搜索樹節點，相差的節點數目正比於樹的高度正比與磁盤io的次數，達到一定數量時，性能差異明顯。

6、為什么btree查找效率高？

多路查找-->降低樹的高度-->減少磁盤io的次數-->節省磁盤訪問的時間-->更快定位到數據庫文件

查找效率高有兩個原因，一是多路性，每個結點有若干個關鍵字，相同數量的 key 在btree中生成的節點要遠遠小於二叉搜索樹節點，相差的節點數目正比於樹的高度正比與磁盤io的次數，達到一定數量時，性能差異明顯。二是平衡性，所以他效率穩定，不像二叉查找樹那樣會退化成鏈表。

7、btree節點如何定義？vs二叉搜索樹 

二叉搜索樹：key、value、left指針、right指針  

btree節點：多個key key1 key2..多個value value1 value2..多個pointer指針 pointer1、pointer2..

8、 b+tree 與B樹的區別

1. 葉子節點包含了所有關鍵字信息以及指向這些關鍵字記錄的指針，並且葉子節點大小本身就是從小到大的順序鏈接。

2.  所有的非終端結點可以看成是索引部分，不含有效信息 (而B 樹的非終節點也包含需要查找的有效信息)

9、 為什么b+tree比btree更適合做文件的索引、數據庫索引？

1.btree在提高磁盤 io 性能同時並沒有解決元素遍歷效率低下的問題，b+tree只要遍歷葉子節點就可遍歷整棵樹。
2.在數據庫中基於范圍的查找很頻繁，btree每次都要從根節點查，效率低。b+tree只要找到范圍左邊界的葉子結點，可以順着葉子結點，找到相應范圍的所有元素。

3. B+-tree的查詢效率更加穩定

由於非終結點並不是最終指向文件內容的結點，而只是葉子結點中關鍵字的索引。所以任何關鍵字的查找必須走一條從根結點到葉子結點的路。所有關鍵字查詢的路徑長度相同，導致每一個數據的查詢效率相當

補充

真實數據庫中的B+樹應該是非常扁平的，也就是說高度非常小，也就說叉數非常多，每個結點的字樹非常多，而且B+樹的索引節點是非常小的，一次性可以加載到內存，這樣就可以用少量的內存換取只需一次訪存即可獲取到數據的恐怖效率。

B+樹的叉數可以達到1000多叉，存儲 22G 容量的表高度也才3層，一次訪存即可獲取數據。

 

10、b+樹和b樹分別有什么應用

 

B樹和B+樹大量應用在數據庫和文件系統當中。但是多采用B+樹，文件系統和數據庫的索引都是存在硬盤上的，並且如果數據量大的話，不一定能一次性加載到內存中。

mongoDB數據庫用的是B樹

11、hashmap為什么用紅黑樹不用b樹

因為如果采用b樹的話，在數據量不是很多的情況下，數據都會“擠在”一個結點里面。這個時候遍歷效率就退化成了鏈表。

4. 解釋一下什么是池化設計思想。什么是數據庫連接池?為什么需要數據庫連接池?

池話設計應該不是一個新名詞。我們常見的如java線程池、jdbc連接池、redis連接池等就是這類設計的代表實現。這種設計會初始預設資源，解決的問題就是抵消每次獲取資源的消耗，如創建線程的開銷，獲取遠程連接的開銷等。就好比你去食堂打飯，打飯的大媽會先把飯盛好幾份放那里，你來了就直接拿着飯盒加菜即可，不用再臨時又盛飯又打菜，效率就高了。除了初始化資源，池化設計還包括如下這些特征：池子的初始值、池子的活躍值、池子的最大值等，這些特征可以直接映射到java線程池和數據庫連接池的成員屬性中。——這篇文章對池化設計思想介紹的還不錯，直接復制過來，避免重復造輪子了。

數據庫連接本質就是一個 socket 的連接。數據庫服務端還要維護一些緩存和用戶權限信息之類的 所以占用了一些內存。我們可以把數據庫連接池是看做是維護的數據庫連接的緩存，以便將來需要對數據庫的請求時可以重用這些連接。為每個用戶打開和維護數據庫連接，尤其是對動態數據庫驅動的網站應用程序的請求，既昂貴又浪費資源。在連接池中，創建連接后，將其放置在池中，並再次使用它，因此不必建立新的連接。如果使用了所有連接，則會建立一個新連接並將其添加到池中。連接池還減少了用戶必須等待建立與數據庫的連接的時間。

   這種設計會初始預設資源，解決的問題就是抵消每次獲取資源和釋放資源造成的開銷。連接池也是這樣，預先創建好一個連接池，在池中創建一定數量的連接，每當用戶需要連接數據庫，就從池中取出一個連接，使用完畢之后放回池中，這既可以減少連接創建和釋放的開銷，便於連接的管理，也可以降低用戶等待數據庫的延遲。

攻擊

 

sql注入攻擊

簡介：

SQL注入是普通常見的網絡攻擊方式之一，它的原理是通過在參數中輸入特殊符號，來篡改並通過程序SQL語句的條件判斷。

比如：

用戶名：1
密  碼：1' OR '1'='1
那么程序接收到參數后，SQL語句就變成了：SELECT * FROM user WHERE name = '1' and password= '1' OR '1'='1 ';

或者

用戶名：1'; DROP DATABASE root;--
密碼：1
那么程序接收到參數后，SQL語句就變成了：SELECT * FROM user WHERE name = '1'; DROP DATABASE root;--and password= '1';

解決辦法：

1. 不允許帶有特殊字符

2. 對單引號或雙引號進行轉義

3. 對 sql 語句進行預編譯，因為 SQL注入攻擊只對SQL語句的編譯過程有破壞作用，進行預編譯后，傳入的參數只作為字符串，不會再進行一次編譯，SQL注入攻擊也就失效了

MySQL 的體系結構

MySQL是由連接池、管理工具和服務、SQL接口、解析器、優化器、緩存、存儲引擎、文件系統組成。

連接池：

由於每次建立連接需要消耗很多時間，連接池的作用就是將這些連接緩存下來，下次可以直接用已經建立好的連接，提升服務器性能。

管理工具和服務：

系統管理和控制工具，例如備份恢復、Mysql復制、集群等

SQL接口：

接受用戶的SQL命令，並且返回用戶需要查詢的結果。比如select from就是調用SQL Interface

解析器: 

SQL命令傳遞到解析器的時候會被解析器驗證和解析。比如驗證是否符合語法樹等

解析器是由Lex和YACC實現的，是一個很長的腳本， 主要功能：

a . 將SQL語句分解成數據結構，並將這個結構傳遞到后續步驟，以后SQL語句的傳遞和處理就是基於這個結構的

b. 如果在分解構成中遇到錯誤，那么就說明這個sql語句是不合理的

優化器：

查詢優化器，SQL語句在查詢之前會使用查詢優化器對查詢進行優化。他使用的是“選取-投影-聯接”策略進行查詢。

用一個例子就可以理解： select uid,name from user where gender = 1;

這個select 查詢先根據where 語句進行選取，而不是先將表全部查詢出來以后再進行gender過濾

這個select查詢先根據uid和name進行屬性投影，而不是將屬性全部取出以后再進行過濾

將這兩個查詢條件聯接起來生成最終查詢結果

緩存器： 

查詢緩存，如果查詢緩存有命中的查詢結果，查詢語句就可以直接去查詢緩存中取數據。

通過LRU算法將數據的冷端溢出，未來得及時刷新到磁盤的數據頁，叫臟頁。

這個緩存機制是由一系列小緩存組成的。比如表緩存，記錄緩存，key緩存，權限緩存等

存儲引擎

通過 show engines; 可以查看數據庫的 存 儲引擎插件

負責MySQL中數據的存儲與提取。 服務器中的查詢執行引擎通過API與存儲引擎進行通信，通過接口屏蔽了不同存儲引擎之間的差異。關系數據庫中數據的存儲是以表的形式存儲的，所以說存儲的一張張的表，而不是一個個的數據庫。MySQL采用插件式的存儲引擎，所以只要給數據庫提供插件，就可以增加存儲引擎，MySql數據庫提供了多種存儲引擎。用戶可以根據不同的需求為數據表選擇不同的存儲引擎，用戶也可以根據自己的需要編寫自己的存儲引擎。甚至一個庫中不同的表使用不同的存儲引擎，這些都是允許的。

MyISAM存儲引擎

由於該存儲引擎不支持事務、也不支持外鍵，所以訪問速度較快。因此當對事務完整性沒有要求並以訪問為主的應用適合使用該存儲引擎。

 

文件：

.frm文件：與表相關的元數據信息都存放在frm文件，包括表結構的定義信息等。

.MYD文件：MyISAM存儲引擎專用，用於存儲MyISAM表的數據

.MYI文件：MyISAM存儲引擎專用，用於存儲MyISAM表的索引相關信息

InnoDB存儲引擎

mysql 5.5版本以后默認的存儲引擎
由於該存儲引擎在事務上具有優勢，即支持具有提交、回滾及崩潰恢復能力等事務特性，他在運行時會在內存中建立緩沖池，用於緩沖數據和索引。支持行鎖，並發度高。主鍵索引為聚簇索引，所以比MyISAM存儲引擎占用更多的磁盤空間。因此當需要頻繁的更新、刪除操作，同時還對事務的完整性要求較高，需要實現並發控制，建議選擇。

 

文件：

.frm文件：與表相關的元數據信息都存放在frm文件，包括表結構的定義信息等。

.ibd文件：存放innodb表的數據文件。

MEMORY

MEMORY存儲引擎存儲數據的位置是內存，因此訪問速度最快，但是安全上沒有保障。適合於需要快速的訪問或臨時表。

BLACKHOLE

黑洞存儲引擎，寫入的任何數據都會消失，可以應用於主備復制中的分發主庫。

存儲引擎的另一個知識總結

InnoDB 和 MyISAM 的區別：

目前比較普及的存儲引擎是MyISAM和InnoDB。MyISAM與InnoDB的主要的不同點在於性能和事務控制上。MyISAM是早期ISAM (Indexed Sequential Access Method 索引順序存取法，MySQL5.0之后已經不支持ISAM了）的擴展實現

ISAM被設計為適合處理讀頻率遠大於寫頻率這樣的情況，因此ISAM以及后來的MyISAM都沒有考慮對事物的支持，排除了TPM，不需要事務記錄，ISAM的查詢效率相當可觀，而且內存占用很少。

MyISAM在繼承了這類優點的同時，與時俱進地提供了大量實用的新特性和相關工具。例如考慮到並發控制，提供了表級鎖

InnoDB被設計成適用於高並發讀寫的情況，支持兼容ACID的事務（類似於PostgreSQL),以及參數 完整性（即對外鍵的支持）。 一般來說，如果需要事務支持，並且有較高的並發讀寫頻率，InnoDB是不錯的選擇。

InnoDB引擎

InnoDB是一個事務型的存儲引擎，支持回滾，設計目標是處理大量數據時提供高性能的服務，它在運行時會在內存中建立緩沖池，用於緩沖數據和索引

InnoDB引擎優點

1、支持事務處理、ACID事務特性；
2、實現了SQL標准的四種隔離級別；
3、支持行級鎖和外鍵約束，行鎖優點是粒度小，適用於高並發的頻繁表修改，高並發使性能優於 MyISAM。缺點是系統消耗較大。4、可以利用事務日志進行數據恢復。

InnoDB引擎缺點

1.  因為它沒有保存表的行數，當使用COUNT統計時會掃描全表。

2、索引不僅緩存自身，也緩存數據，相比 MyISAM 需要更大的內存。

MyISAM引擎

MyISAM 是 MySQL 5.5.5 之前的默認引擎，它的設計目標是快速讀取。

MyISAM引擎優點

1.高性能讀取；
2.因為它保存了表的行數，當使用COUNT統計時不會掃描全表；

MyISAM引擎缺點

1、鎖級別為表鎖，表鎖優點是開銷小，加鎖快；缺點是鎖粒度大，發生鎖沖動概率較高，容納並發能力低，這個引擎適合查詢為主的業務。
2、此引擎不支持事務，也不支持外鍵。
3、INSERT和UPDATE操作需要鎖定整個表；

適用場景

MyISAM適合：(1)做很多count 的計算；(2)插入不頻繁，查詢非常頻繁；(3)沒有事務。
InnoDB適合：(1)可靠性要求比較高，或者要求事務；(2)表更新和查詢都相當的頻繁，並且表鎖定的機會比較大的情況。

補充：

OLTP(聯機事務處理)和OLAP(聯機分析處理)

OLTP用於存儲和管理日常操作的數據;

OLAP用於分析這些數據