一、MySQL的主要適用場景

1、Web網站系統

2、日誌記錄系統

3、數據倉庫系統

4、嵌入式系統

二、MySQL架構圖：

三、MySQL存儲引擎概述

1）MyISAM存儲引擎

MyISAM存儲引擎的表在數據庫中，每一個表都被存放為三個以表名命名的物理文件。首先肯定會有任何存儲引擎都不可缺少的存放表結構定義信息的.frm文件，另外還有.MYD和.MYI文件，分別存放了表的數據（.MYD）和索引數據（.MYI）。每個表都有且僅有這樣三個文件做為MyISAM存儲類型的表的存儲，也就是說不管這個表有多少個索引，都是存放在同一個.MYI文件中。

MyISAM支持以下三種類型的索引：

1、B-Tree索引

B-Tree索引，顧名思義，就是所有的索引節點都按照balancetree的數據結構來存儲，所有的索引數據節點都在葉節點。

2、R-Tree索引

R-Tree索引的存儲方式和b-tree索引有一些區別，主要設計用於為存儲空間和多維數據的字段做索引，所以目前的MySQL版本來說，也僅支持geometry類型的字段作索引。

3、Full-text索引

Full-text索引就是我們長說的全文索引，他的存儲結構也是b-tree。主要是為了解決在我們需要用like查詢的低效問題。

2）Innodb 存儲引擎

1、支持事務安裝

2、數據多版本讀取

3、鎖定機制的改進

4、實現外鍵

3）NDBCluster

NDB存儲引擎也叫NDBCluster存儲引擎，主要用於MySQLCluster分布式集群環境，Cluster是MySQL從5.0版本才開始提供的新功能。

4）Merge存儲引擎

MERGE存儲引擎，在MySQL用戶手冊中也提到了，也被大家認識為MRG_MyISAM引擎。Why？因為MERGE存儲引擎可以簡單的理解為其功能就是實現了對結構相同的MyISAM表，通過一些特殊的包裝對外提供一個單一的訪問入口，以達到減小應用的復雜度的目的。要創建MERGE表，不僅僅基表的結構要完全一致，包括字段的順序，基表的索引也必須完全一致。

5）Memory存儲引擎

Memory存儲引擎，通過名字就很容易讓人知道，他是一個將數據存儲在內存中的存儲引擎。Memory存儲引擎不會將任何數據存放到磁盤上，僅僅存放了一個表結構相關信息的.frm文件在磁盤上面。所以一旦MySQLCrash或者主機Crash之後，Memory的表就只剩下一個結構了。Memory表支持索引，並且同時支持Hash和B－Tree兩種格式的索引。由於是存放在內存中，所以Memory都是按照定長的空間來存儲數據的，而且不支持BLOB和TEXT類型的字段。Memory存儲引擎實現頁級鎖定。

6）BDB存儲引擎

BDB存儲引擎全稱為BerkeleyDB存儲引擎，和Innodb一樣，也不是MySQL自己開發實現的一個存儲引擎，而是由SleepycatSoftware所提供，當然，也是開源存儲引擎，同樣支持事務安全。

7）FEDERATED存儲引擎

FEDERATED存儲引擎所實現的功能，和Oracle的DBLINK基本相似，主要用來提供對遠程MySQL服務器上面的數據的訪問接口。如果我們使用源碼編譯來安裝MySQL，那麽必須手工指定啟用FEDERATED存儲引擎才行，因為MySQL默認是不起用該存儲引擎的。

8）ARCHIVE存儲引擎

ARCHIVE存儲引擎主要用於通過較小的存儲空間來存放過期的很少訪問的歷史數據。ARCHIVE表不支持索引，通過一個.frm的結構定義文件，一個.ARZ的數據壓縮文件還有一個.ARM的meta信息文件。由於其所存放的數據的特殊性，ARCHIVE表不支持刪除，修改操

作，僅支持插入和查詢操作。鎖定機制為行級鎖定。

9）BLACKHOLE存儲引擎

BLACKHOLE存儲引擎是一個非常有意思的存儲引擎，功能恰如其名，就是一個“黑洞”。就像我們unix系統下面的“/dev/null”設備一樣，不管我們寫入任何信息，都是有去無回。

10）CSV存儲引擎

CSV存儲引擎實際上操作的就是一個標準的CSV文件，他不支持索引。起主要用途就是大家有些時候可能會需要通過數據庫中的數據導出成一份報表文件，而CSV文件是很多軟件都支持的一種較為標準的格式，所以我們可以通過先在數據庫中建立一張CVS表，然後將生成的報表信息插入到該表，即可得到一份CSV報表文件了。

四、影響MySQLServer性能的相關因素

1商業需求對性能的影響

典型需求：一個論壇帖子總量的統計，要求：實時更新。

2系統架構及實現對性能的影響

以下幾類數據都是不適合在數據庫中存放的：

二進制多媒體數據

流水隊列數據

超大文本數據

通過Cache技術來提高系統性能：

系統各種配置及規則數據；

活躍用戶的基本信息數據；

活躍用戶的個性化定制信息數據；

準實時的統計信息數據；

其他一些訪問頻繁但變更較少的數據；

3 Query語句對系統性能的影響

需求：取出某個group（假設id為1）下的用戶編號（id），用戶昵稱（nick_name），並按照加入組的時間（user_group.gmt_create）來進行倒序排列，取出前20個。

解決方案一：

SELECT id,nick_name FROM user,user_group WHERE user_group.group_id=1 and user_group.user_id=user.id ORDER BY user_group.gmt_create desc limit 100,20;

解決方案二：

SELECT user.id,user.nick_name FROM(
SELECT user_id
FROM user_group
WHERE user_group.group_id=1
ORDER BY gmt_create desc
limit 100,20)t,user
WHERE t.user_id=user.id;

通過比較兩個解決方案的執行計劃，我們可以看到第一中解決方案中需要和user表參與Join的記錄數MySQL通過統計數據估算出來是31156，也就是通過user_group表返回的所有滿足group_id=1的記錄數（系統中的實際數據是20000）。而第二種解決方案的執行計劃中，user表參與Join的數據就只有20條，兩者相差很大，我們認為第二中解決方案應該明顯優於第一種解決方案。

4 Schema設計對系統的性能影響

盡量減少對數據庫訪問的請求。

盡量減少無用數據的查詢請求。

5硬件環境對系統性能的影響

1、典型OLTP應用系統

對於各種數據庫系統環境中大家最常見的OLTP系統，其特點是並發量大，整體數據量比較多，但每次訪問的數據比較少，且訪問的數據比較離散，活躍數據占總體數據的比例不是太大。對於這類系統的數據庫實際上是最難維護，最難以優化的，對主機整體性能要求也是最高的。因為不僅訪問量很高，數據量也不小。

針對上面的這些特點和分析，我們可以對OLTP的得出一個大致的方向。

雖然系統總體數據量較大，但是系統活躍數據在數據總量中所占的比例不大，那麽我們可以通過擴大內存容量來盡可能多的將活躍數據cache到內存中；

雖然IO訪問非常頻繁，但是每次訪問的數據量較少且很離散，那麽我們對磁盤存儲的要求是IOPS表現要很好，吞吐量是次要因素；

並發量很高，CPU每秒所要處理的請求自然也就很多，所以CPU處理能力需要比較強勁；

雖然與客戶端的每次交互的數據量並不是特別大，但是網絡交互非常頻繁，所以主機與客戶端交互的網絡設備對流量能力也要求不能太弱。

2、典型OLAP應用系統

用於數據分析的OLAP系統的主要特點就是數據量非常大，並發訪問不多，但每次訪問所需要檢索的數據量都比較多，而且數據訪問相對較為集中，沒有太明顯的活躍數據概念。

基於OLAP系統的各種特點和相應的分析，針對OLAP系統硬件優化的大致策略如下：

數據量非常大，所以磁盤存儲系統的單位容量需要盡量大一些；

單次訪問數據量較大，而且訪問數據比較集中，那麽對IO系統的性能要求是需要有盡可能大的每秒IO吞吐量，所以應該選用每秒吞吐量盡可能大的磁盤；

雖然IO性能要求也比較高，但是並發請求較少，所以CPU處理能力較難成為性能瓶頸，所以CPU處理能力沒有太苛刻的要求；

雖然每次請求的訪問量很大，但是執行過程中的數據大都不會返回給客戶端，最終返回給客戶端的數據量都較小，所以和客戶端交互的網絡設備要求並不是太高；

此外，由於OLAP系統由於其每次運算過程較長，可以很好的並行化，所以一般的OLAP系統都是由多臺主機構成的一個集群，而集群中主機與主機之間的數據交互量一般來說都是非常大的，所以在集群中主機之間的網絡設備要求很高。

3、除了以上兩個典型應用之外，還有一類比較特殊的應用系統，他們的數據量不是特別大，但是訪問請求及其頻繁，而且大部分是讀請求。可能每秒需要提供上萬甚至幾萬次請求，每次請求都非常簡單，可能大部分都只有一條或者幾條比較小的記錄返回，就比如基於數據庫的DNS服務就是這樣類型的服務。

雖然數據量小，但是訪問極其頻繁，所以可以通過較大的內存來cache住大部分的數據，這能夠保證非常高的命中率，磁盤IO量比較小，所以磁盤也不需要特別高性能的；

並發請求非常頻繁，比需要較強的CPU處理能力才能處理；

雖然應用與數據庫交互量非常大，但是每次交互數據較少，總體流量雖然也會較大，但是一般來說普通的千兆網卡已經足夠了。

五、MySQL 鎖定機制簡介

行級鎖定（row-level）

表級鎖定（table-level）

頁級鎖定（page-level）

在MySQL數據庫中，使用表級鎖定的主要是MyISAM，Memory，CSV等一些非事務性存儲引擎，而使用行級鎖定的主要是Innodb存儲引擎和NDBCluster存儲引擎，頁級鎖定主要是BerkeleyDB存儲引擎的鎖定方式。

六、MySQL Query的優化

Query語句的優化思路和原則主要提現在以下幾個方面：

1. 優化更需要優化的Query；

2. 定位優化對象的性能瓶頸；

3. 明確的優化目標；

4. 從Explain入手；

5. 多使用profile

6. 永遠用小結果集驅動大的結果集；

7. 盡可能在索引中完成排序；

8. 只取出自己需要的Columns；

9. 僅僅使用最有效的過濾條件；

10.盡可能避免復雜的Join和子查詢；

合理設計並利用索引

1）B-Tree索引

一般來說，MySQL中的B-Tree索引的物理文件大多都是以BalanceTree的結構來存儲的，也就是所有實際需要的數據都存放於Tree的LeafNode，而且到任何一個LeafNode的最短路徑的長度都是完全相同的，所以我們大家都稱之為B-Tree索引當然，可能各種數據庫（或MySQL的各種存儲引擎）在存放自己的B-Tree索引的時候會對存儲結構稍作改造。如Innodb存儲引擎的B-Tree索引實際使用的存儲結構實際上是B+Tree，也就是在B-Tree數據結構的基礎上做了很小的改造，在每一個LeafNode上面出了存放索引鍵的相關信息之外，還存儲了指向與該LeafNode相鄰的後一個LeafNode的指針信息，這主要是為了加快檢索多個相鄰LeafNode的效率考慮。

2）Hash索引

Hash索引在MySQL中使用的並不是很多，目前主要是Memory存儲引擎使用，而且在Memory存儲引擎中將Hash索引作為默認的索引類型。所謂Hash索引，實際上就是通過一定的Hash算法，將需要索引的鍵值進行Hash運算，然後將得到的Hash值存入一個Hash表中。然後每次需要檢索的時候，都會將檢索條件進行相同算法的Hash運算，然後再和Hash表中的Hash值進行比較並得出相應的信息。

Hash索引僅僅只能滿足“=”,“IN”和“<=>”查詢，不能使用範圍查詢；

Hash索引無法被利用來避免數據的排序操作；

Hash索引不能利用部分索引鍵查詢；

Hash索引在任何時候都不能避免表掃面；

Hash索引遇到大量Hash值相等的情況後性能並不一定就會比B-Tree索引高；

3）Full-text索引

Full-text索引也就是我們常說的全文索引，目前在MySQL中僅有MyISAM存儲引擎支持，而且也並不是所有的數據類型都支持全文索引。目前來說，僅有CHAR，VARCHAR和TEXT這三種數據類型的列可以建Full-text索引。

索引能夠極大的提高數據檢索效率，也能夠改善排序分組操作的性能，但是我們不能忽略的一個問題就是索引是完全獨立於基礎數據之外的一部分數據，更新數據會帶來的IO量和調整索引所致的計算量的資源消耗。

是否需要創建索引，幾點原則：較頻繁的作為查詢條件的字段應該創建索引；唯一性太差的字段不適合單獨創建索引，即使頻繁作為查詢條件；更新非常頻繁的字段不適合創建索引；

不會出現在WHERE子句中的字段不該創建索引；

Join語句的優化

盡可能減少Join語句中的NestedLoop的循環總次數；“永遠用小結果集驅動大的結果集”。

優先優化NestedLoop的內層循環；

保證Join語句中被驅動表上Join條件字段已經被索引；

當無法保證被驅動表的Join條件字段被索引且內存資源充足的前提下，不要太吝惜JoinBuffer的設置；

ORDER BY，GROUP BY和DISTINCT優化

1）ORDER BY的實現與優化

優化Query語句中的ORDER BY的時候，盡可能利用已有的索引來避免實際的排序計算，可以很大幅度的提升ORDER BY操作的性能。

優化排序：

1.加大max_length_for_sort_data參數的設置；

2.去掉不必要的返回字段；

3.增大sort_buffer_size參數設置；

2）GROUP BY的實現與優化

由於GROUP BY實際上也同樣需要進行排序操作，而且與ORDER BY相比，GROUP BY主要只是多了排序之後的分組操作。當然，如果在分組的時候還使用了其他的一些聚合函數，那麽還需要一些聚合函數的計算。所以，在GROUP BY的實現過程中，與ORDER BY一樣也可以利用到索引。

3）DISTINCT的實現與優化

DISTINCT實際上和GROUP BY的操作非常相似，只不過是在GROUP BY之後的每組中只取出一條記錄而已。所以，DISTINCT的實現和GROUP BY的實現也基本差不多，沒有太大的區別。同樣可以通過松散索引掃描或者是緊湊索引掃描來實現，當然，在無法僅僅使用索引即能完成DISTINCT的時候，MySQL只能通過臨時表來完成。但是，和GROUP BY有一點差別的是，DISTINCT並不需要進行排序。也就是說，在僅僅只是DISTINCT操作的Query如果無法僅僅利用索引完成操作的時候，MySQL會利用臨時表來做一次數據的“緩存”，但是不會對臨時表中的數據進行filesort操作。

七、MySQL數據庫Schema設計的性能優化

高效的模型設計

適度冗余-讓Query盡兩減少Join

大字段垂直分拆-summary表優化

大表水平分拆-基於類型的分拆優化

統計表-準實時優化

合適的數據類型

時間存儲格式總類並不是太多，我們常用的主要就是DATETIME，DATE和TIMESTAMP這三種了。從存儲空間來看TIMESTAMP最少，四個字節，而其他兩種數據類型都是八個字節，多了一倍。而TIMESTAMP的缺點在於他只能存儲從1970年之後的時間，而另外兩種時間類型可以存放最早從1001年開始的時間。如果有需要存放早於1970年之前的時間的需求，我們必須放棄TIMESTAMP類型，但是只要我們不需要使用1970年之前的時間，最好盡量使用TIMESTAMP來減少存儲空間的占用。

字符存儲類型

CHAR[(M)]類型屬於靜態長度類型，存放長度完全以字符數來計算，所以最終的存儲長度是基於字符集的，如latin1則最大存儲長度為255字節，但是如果使用gbk則最大存儲長度為510字節。CHAR類型的存儲特點是不管我們實際存放多長數據，在數據庫中都會存放M個字符，不夠的通過空格補上，M默認為1。雖然CHAR會通過空格補齊存放的空間，但是在訪問數據的時候，MySQL會忽略最後的所有空格，所以如果我們的實際數據中如果在最後確實需要空格，則不能使用CHAR類型來存放。

VARCHAR[(M)]屬於動態存儲長度類型，僅存占用實際存儲數據的長度。TINYTEXT，TEXT，MEDIUMTEXT和LONGTEXT這四種類型同屬於一種存儲方式，都是動態存儲長度類型，不同的僅僅是最大長度的限制。

事務優化

1. 臟讀：臟讀就是指當一個事務正在訪問數據，並且對數據進行了修改，而這種修改還沒有提交到數據庫中，這時，另外一個事務也訪問這個數據，然後使用了這個數據。

2. 不可重復讀：是指在一個事務內，多次讀同一數據。在這個事務還沒有結束時，另外一個事務也訪問該同一數據。那麽，在第一個事務中的兩次讀數據之間，由於第二個事務的修改，那麽第一個事務兩次讀到的的數據可能是不一樣的。這樣就發生了在一個事務內兩次讀到的數據是不一樣的，因此稱為是不可重復讀。

3. 幻讀：是指當事務不是獨立執行時發生的一種現象，例如第一個事務對一個表中的數據進行了修改，這種修改涉及到表中的全部數據行。同時，第二個事務也修改這個表中的數據，這種修改是向表中插入一行新數據。那麽，以後就會發生操作第一個事務的用戶發現表中還有沒有修改的數據行，就好象發生了幻覺一樣。

Innodb在事務隔離級別方面支持的信息如下：

1.READ UNCOMMITTED

常被成為Dirty Reads（臟讀），可以說是事務上的最低隔離級別：在普通的非鎖定模式下SELECT的執行使我們看到的數據可能並不是查詢發起時間點的數據，因而在這個隔離度下是非Consistent Reads（一致性讀）；

2.READ COMMITTED

這一隔離級別下，不會出現DirtyRead，但是可能出現Non-RepeatableReads(不可重復讀)和PhantomReads（幻讀）。

3. REPEATABLE READ

REPEATABLE READ隔離級別是InnoDB默認的事務隔離級。在REPEATABLE READ隔離級別下，不會出現DirtyReads，也不會出現Non-Repeatable Read，但是仍然存在PhantomReads的可能性。

4.SERIALIZABLE

SERIALIZABLE隔離級別是標準事務隔離級別中的最高級別。設置為SERIALIZABLE隔離級別之後，在事務中的任何時候所看到的數據都是事務啟動時刻的狀態，不論在這期間有沒有其他事務已經修改了某些數據並提交。所以，SERIALIZABLE事務隔離級別下，PhantomReads也不會出現。

八、可擴展性設計之數據切分

數據的垂直切分

數據的垂直切分，也可以稱之為縱向切分。將數據庫想象成為由很多個一大塊一大塊的“數據塊”（表）組成，我們垂直的將這些“數據塊”切開，然後將他們分散到多臺數據庫主機上面。這樣的切分方法就是一個垂直（縱向）的數據切分。

垂直切分的優點

◆數據庫的拆分簡單明了，拆分規則明確；

◆應用程序模塊清晰明確，整合容易；

◆數據維護方便易行，容易定位；

垂直切分的缺點

◆部分表關聯無法在數據庫級別完成，需要在程序中完成；

◆對於訪問極其頻繁且數據量超大的表仍然存在性能平靜，不一定能滿足要求；

◆事務處理相對更為復雜；

◆切分達到一定程度之後，擴展性會遇到限制；

◆過讀切分可能會帶來系統過渡復雜而難以維護。

數據的水平切分

數據的垂直切分基本上可以簡單的理解為按照表按照模塊來切分數據，而水平切分就不再是按照表或者是功能模塊來切分了。一般來說，簡單的水平切分主要是將某個訪問極其平凡的表再按照某個字段的某種規則來分散到多個表之中，每個表中包含一部分數據。

水平切分的優點

◆表關聯基本能夠在數據庫端全部完成；

◆不會存在某些超大型數據量和高負載的表遇到瓶頸的問題；

◆應用程序端整體架構改動相對較少；

◆事務處理相對簡單；

◆只要切分規則能夠定義好，基本上較難遇到擴展性限制；

水平切分的缺點

◆切分規則相對更為復雜，很難抽象出一個能夠滿足整個數據庫的切分規則；

◆後期數據的維護難度有所增加，人為手工定位數據更困難；

◆應用系統各模塊耦合度較高，可能會對後面數據的遷移拆分造成一定的困難。

數據切分與整合中可能存在的問題

1.引入分布式事務的問題

完全可以將一個跨多個數據庫的分布式事務分拆成多個僅處於單個數據庫上面的小事務，並通過應用程序來總控各個小事務。當然，這樣作的要求就是我們的俄應用程序必須要有足夠的健壯性，當然也會給應用程序帶來一些技術難度。

2.跨節點Join的問題

推薦通過應用程序來進行處理，先在驅動表所在的MySQLServer中取出相應的驅動結果集，然後根據驅動結果集再到被驅動表所在的MySQL Server中取出相應的數據。

3.跨節點合並排序分頁問題

從多個數據源並行的取數據，然後應用程序匯總處理。

九、可擴展性設計之Cache與Search的利用

通過引入Cache（Redis、Memcached），減少數據庫的訪問，增加性能。

通過引入Search（Lucene、Solr、ElasticSearch），利用搜索引擎高效的全文索引和分詞算法，以及高效的數據檢索實現，來解決數據庫和傳統的Cache軟件完全無法解決的全文模糊搜索、分類統計查詢等功能。

數據庫性能優化