Mysql技術內幕筆記

mysql由如下幾個部分組成：

鏈接池組件

管理服務和工具組件

sql接口組價

查詢分析器組價

優化器組價

緩存（cache）組價

插件式存儲引擎

物理文件。

能夠看出，MySQL數據庫區別於其餘數據庫的最重要的一個特色就是其插件式的表存儲引擎。存儲引擎是基於表的，而不是數據庫。是底層物理結構的實現，每一個存儲引擎開發者能夠按照本身的意願來開發。

mysql數據庫的核心在於存儲引擎。innodb甚至是mysql數據庫OLTP應用中使用最普遍的存儲引擎。

InnoDB存儲引擎：

第一個完整支持ACID事務MYSQL存儲引擎

設計目標主要是在線事務處理。特色：行鎖設計、支持外鍵，並支持相似於Oracle的非鎖定讀，即默認讀取操做不會產生鎖。經過多版本併發控制來得到高併發性，而且實現了SQL標誌的4種隔離級別，默認爲repeatable級別。使用一種next-key-locking的策略來避免幻讀，此外innoDB提供了插入緩衝、二次寫、自適應哈希索引、預讀等高性能和高可用的功能。表中數據的存儲採用了彙集方式，所以每張表的存儲都是按照主鍵的順序進行存放。沒有顯示定義主鍵的話，innoDB會爲每一行生成一個6本身的ROWID，並以此爲主鍵。

MYISAM:

不支持事務，表鎖設計，支持全文索引，只要面向一些OLAP的數據庫應用。緩衝池只緩存索引文件，而不是數據文件，這點和大多數的數據庫都很是不一樣。

 

InnoDB體系架構：

1.後臺線程：

1）master Thread

2）IO Thread

3）Purge Thread

4）Page Cleaner Thread

2.內存

1）緩衝池

2）LRU List、Free List和Flush List

3）重作日誌緩衝

4）額外的內存池

NDB:

是一個集羣存儲引擎，相似於Oracle的RAC集羣。NDB的特色使數據所有放在內存中（5.1之後能夠將非索引數據放在磁盤上），所以主鍵查找的速度極快，而且經過添加NDB數據存儲節點能夠先行地提升數據庫性能，是高可用、高性能的集羣系統。ndb的連接操做join實在mysql數據庫層完成的，而不是存儲引擎層，意味着負責鏈接操做須要巨大的網絡開銷，查詢速度很慢。

memory存儲引擎：

將表中的數據存放在內存中，若是數據重啓或發生崩潰，表中的數據將消失。很是適合存儲臨時數據的臨時表，以及數據倉庫中的維度表。默認使用哈希索引，而不是咱們熟悉的B+數索引。雖然速度快，只支持表鎖，併發性能較差，而且不支持text和bolb類型。存儲變長字段varchar是按照定長字段（char）的方式進行的，所以會浪費內存。

Achive存儲引擎：

只支持insert和select。5.1之後開始支持索引。使用zlib算法將數據行進行壓縮後存儲，壓縮比通常可達1:10,。很是適合存儲歸檔信息，如日誌信息。使用行鎖來實現高併發的插入操做，可是其自己並非事務安全的存儲引擎，其設計目標主要是提升告訴的插入和壓縮功能。

Federated存儲引擎：

並不存儲表，只是指向一臺遠程MySQL數據庫服務器上的表。

Maria存儲引擎：

新開發的引擎，能夠當作是myisam的後續版本。特色：支持緩存數據和索引文件，應用了行鎖設計，提供了mvcc功能，支持事務和非事務安全的選項，以及更好的BLOB字符類型的處理性能。

 

第四章 表

4.1索引組織表

 在innoDB存儲引擎中,表都是根據組件順序組織存放的。這種存儲方式的表稱爲索引組織表。在inndb存儲引擎中，每張表都有個主鍵，若是在建立表時沒有顯示的定義主鍵，則inndb存儲引擎會按以下方式選擇或建立主鍵:
1）首先判斷表中是否有非空的惟一索引。若是有，則該列即爲主鍵。
2）若是不符合上述條件，innodb存儲引擎自動建立一個六字節大小的指針。
當表中多個非空惟一索引時。inndb存儲引擎將選擇見表時第一個定義的非空惟一索引主鍵 

段：表空間是由各個段組成的，常見的段有數據段、索引段、回滾段等。innodb存儲引擎表示索引組織的，所以數據即索引，索引即數據。那麼數據段即爲B+數的葉子節點，索引段即爲B+數的非索引節點。

區：區是由連續頁組成的空間，在任何狀況下每一個區的大小都是1MB。爲了保證區中頁的連續性，innoDB存儲引擎一次從磁盤申請4-5個區。默認狀況下，innoDB存儲引擎頁的大小爲16KB，即一個區中一共有64個連續的頁。

頁：頁是innoDB磁盤管理的最小單位。innoDB中，默認每一個頁大小爲16KB。

常見的頁類型有：數據頁，undo頁，系統頁，事務數據頁，插入緩衝位圖頁，插入緩衝空閒列表頁、未壓縮的二進制大對象頁、壓縮的二級制大對象頁。

行：innoDB存儲引擎是面向行的，也就是數據是按行進行存放的。

MySQL infobright存儲引擎就是按列來存放數據的。相似的還有sybase IQ、Google Big Table，這對於數據倉庫下的分析類sql語句的執行及數據壓縮很是有幫助。

行記錄格式：Compact和Redundant

varchar類型能夠存放65535字節（實際是65532左右，有其餘開銷）

其中65535長度是多元varchar長度總和。

4.6約束

數據完整性有如下三種形式：

實體完整性、域完整性還有參照完整性。

實體完整性：保證表中有一個主鍵

域完整性：保證數據每列的值知足特定的條件。

參照完整性：保證兩張表之間的關係。

 4.7視圖

在MySQL中，視圖是一個命名的虛表，它由一個sql查詢來定義，能夠當作表使用。與持久表不一樣的是，視圖中的數據沒有實際的物理存儲。

視圖的做用：被當作一個抽象裝置，特別是對於一些應用程序，程序自己不須要關心基表的結構，只須要按照視圖定義來取數據或更新數據，所以在必定程度上起到一個安全層的做用。

4.8分區表

分區功能並非在存儲引擎層完成的，所以不是隻有innoDB才支持分區，常見的存儲引擎innoDB、myisam、nbd都支持，有些如csv、fedorated、merge等不支持。

分區：將一個表或索引分解爲更小、更可管理的部分。邏輯上來說，只有一個表或索引，可是物理上這個表或索引可能由數十個物理分區組成。MySQL支持水平分區，不支持垂直分區。此外，MySQL數據庫的分區是局部分區索引，一個分區中既放了數據又放了索引。而全局分區是指，數據存放在各個分區中，可是索引數據的索引放在一個對象中。MySQL暫時不支持全局分區。

分區類型：range分區、List分區、Hash分區、key分區、column分區。

通常狀況下：OLAP應用如數據倉庫、數據集市，分區的確是能夠很好的挺高查詢的性能，由於OLAP應用大多數查詢須要頻繁地掃描一張很大的表。對於OLTP應用，分區應該格外當心。B+樹索引能夠很好的完成操做，不須要分區的幫助，而且設計很差的分區會帶來嚴重的性能問題。

第5章 索引

索引太多，應用程序的性能可能會受到影響。而索引太少，對查詢性能又會產出影響，要找到一個平衡點。

innoDB支持的索引：

B+樹索引

全文索引

哈希索引：innoDB支持的哈希索引是自適應的，會根據表的使用狀況自動爲表生成哈希索引，不能人爲干預是否在一張表中生成哈希索引。

B+樹：並不能找到一個給定健值的具體行，能找到的知識被查找數據行所在的頁。而後數據庫經過頁讀入到內存，再在內存中進行查找，最後獲得要查找的數據。是目前關係型數據庫系統中查找最爲經常使用和最有效的索引。

B+樹索引分爲彙集索引和輔助索引。葉子節點存放着索引的數據。彙集索引與輔助索引不一樣的是，葉子節點存放的是不是一整行的信息。

彙集索引：按照每張表的主鍵構造一顆B+樹，同時葉子節點中存放的即爲整張表的行記錄數據，也將彙集索引的葉子節點成爲數據頁。彙集索引的這個特徵決定了索引組織表中數據也是索引的一部分。每張表只能有一個彙集索引。在多數狀況下，查詢優化器傾向於採用彙集索引。由於彙集索引可以在B+樹索引的葉子節點上直接找到數據。因爲定義了數據的邏輯結構，彙集索引可以特別快的訪問針對範圍值的查詢。

輔助索引（非彙集索引）：葉子節點並不包含行記錄的所有數據。