MySQL性能調優與架構設計-架構篇

時間 2019-11-20

標籤 mysql 性能架構設計欄目 MySQL 简体版

原文原文鏈接

架構篇（1）讀書筆記前端

1.Scale（擴展):從數據庫來看,就是讓數據庫可以提供更強的服務能力mysql

ScaleOut: 是經過增長處理節點的方式來提升總體處理能力ios

ScaleUp: 是經過增長當前處理節點的處理能力來提升總體的處理能力算法

2.事務最小化原則:sql

避免分佈式事務的解決方案shell

a)進行ScaleOut 設計的時候合理設計切分規則，儘量保證事務所需數據在同一個MySQLServer 上，避免分佈式事務。大多數時候也只能兼顧到一些大部分的核心事務，不是一個很完美的解決方案。數據庫

b)大事務切分紅多個小事務，數據庫保證各個小事務的完整性，應用控制各個小事務之間的總體事務完整性。後端

c)結合上述兩種解決方案，整合各自的優點，避免各自的弊端。核心業務的事務用a)方案保證,其餘的用b)保證,要仔細分析,是否須要事務,若是不須要的話,就不要引入事務.緩存

3.數據一致性原則.安全

如何在ScaleOut 的同時又較好的保證數據一致性呢？

==>BASE模型,即：基本可用，柔性狀態，基本一致和最終一致。這幾個詞看着挺複雜挺深奧，其實你們能夠簡單的理解爲非實時的一致性原則。也就是說，應用系統經過相關的技術實現，讓整個系統在知足用戶使用的基礎上，容許數據短期內處於非實時狀態，而經過後續技術來保證數據在最終保證處於一致狀態。

但也有問題:

第一個問題就是咱們須要讓全部數據都是非實時一致嗎？

==>若是不是全部的數據都是非實時一致，那咱們又該如何來肯定哪些數據須要實時一致哪些數據又只須要非實時的最終一致呢？其實這基本能夠說是一個各模塊業務優先級的劃分，對於優先級高的天然是規屬於保證數據實時一致性的陣營，而優先級略低的應用，則能夠考慮劃分到容許短期端內不一致而最終一致的陣營。這是一個很是棘手的問題。須要經過很是詳細的分析和仔細的評估才能做出決定。由於不是全部數據均可以出如今系統能不短期段內不一致狀態，也不是全部數據均可以經過後期處理的使數據最終達到一致的狀態，因此之少這兩類數據就是須要實時一致的。

如何讓系統中的不一致數據達到最終一致？

==>通常來講，咱們必須將這類數據所設計到的業務模塊和須要實時一致數據的業務模塊明確的劃分開來。而後經過相關的異步機制技術，利用相應的後臺進程，經過系統中的數據，日誌等信息將當前並不一致的數據進行進一步處理，使最終數據處於徹底一致狀態。對於不一樣的模塊，使用不一樣的後臺進程，既能夠避免數據出現紊亂，也能夠併發執行，提升處理效率。

避免實時一致與最終一致兩類數據的前臺在線交互。

==>因爲兩類數據狀態的不一致性，極可能會致使兩類數據在交互過程當中出現紊亂，應該儘可能讓全部非實時一致的數據和實時一致數據在應用程序中獲得有效的隔離。甚至在有些特別的場景下，記錄在不一樣的MySQLServer中來進行物理隔離都是有必要的。

4.高可用以及數據安全原則:

通過ScaleOut設計以後，系統總體可擴展性確實是會獲得很大的提升，總體性能天然也很容易獲得較大的改善。可是，系統總體的可用性維護方面倒是變得比之前更爲困難。由於系統總體架構複雜了，不管是應用程序仍是數據庫環境方面都會比原來更爲龐大，更爲複雜。這樣所帶來的最直接影響就是維護難度更大，系統監控更難。

ScaleOut 設計過程當中另外一個原則，也就是高可用性的原則。不論如何調整設計系統的架構，系統的總體可用性不能被下降。

數據安全:

==>咱們必須保證在出現軟/硬件故障的時候，可以保證咱們的數據不會出現丟失。數據一旦丟失，根本就無可用性可言了。

==>最好的辦法就是經過冗餘機制來保證。全部軟硬件設備都去除單點隱患，全部數據都存在多份拷貝。能夠經過MySQLReplication，MySQLCluster 等技術來實現。

架構篇（2）讀書筆記

mysqlreplication:

原理:

Mysql的Replication是一個異步的複製過程，在Master與Slave之間的實現整個複製過程主要由三個線程來完成，其中兩個線程（Sql線程和IO線程）在Slave端，另一個線程（IO線程）在Master端。

要實現MySQL的Replication，首先必須打開Master端的BinaryLog（mysqlbin.xxxxxx）功能，不然沒法實現。由於整個複製過程實際上就是Slave從Master端獲取該日誌而後再在本身身上徹底順序的執行日誌中所記錄的各類操做。

複製的過程:

1.Slave 上面的IO線程鏈接上Master，並請求從指定日誌文件的指定位置（或者從最開始的日誌）以後的日誌內容；

2.Master 接收到來自Slave的IO線程的請求後，經過負責複製的IO線程根據請求信息讀取指定日誌指定位置以後的日誌信息，返回給Slave端的IO線程。返回信息中除了日誌所包含的信息以外，還包括本次返回的信息在Master端的BinaryLog文件的名稱以及在BinaryLog 中的位置；

3.Slave 的IO線程接收到信息後，將接收到的日誌內容依次寫入到Slave端的RelayLog 文件(mysql-relay-bin.xxxxxx)的最末端，並將讀取到的Master端的binlog的文件名和位置記錄到master-info文件中，以便在下一次讀取的時候可以清楚的高速Master「我須要從某個bin-log的哪一個位置開始日後的日誌內容，請發給我」

4.Slave 的SQL線程檢測到RelayLog 中新增長了內容後，會立刻解析該Log文件中的內容成爲在Master端真實執行時候的那些可執行的Query語句，並在自身執行這些Query。這樣，實際上就是在Master端和Slave端執行了一樣的Query，因此兩端的數據是徹底同樣的。

複製的級別:能夠基於語句的/也能夠基於一條記錄的

記錄級別:爲每一行都生成sql,信息量大.

語句級別:性能高.可是bug多.儘可能少使用存儲過程.

經常使用複製架構:

Master-Slaves:

90%的場合都是這種一個master,多個slave的架構模式.主要用於讀壓力比較大的應用.對於對於數據實時性要求不是過高的系統,只要經過廉價的pcserver就能夠擴展slave的數量.將讀壓力分散到多臺slave機器上.架構圖:

w repl r

client---> master -----> slave <----client

|---> salve <----client

dualmaster 複製架構:

爲了解決主機down機,從機迅速切換成主機的架構方式.

實際上就是兩個MySQLServer 互相將對方做爲本身的Master，本身做爲對方的Slave來進行復制。這樣，任何一方所作的變動，都會經過複製應用到另一方的數據庫中。

不會形成循環複製:在MySQL的BinaryLog 中記錄了當前MySQL的server-id，並且這個參數也是咱們搭建MySQLReplication 的時候必須明確指定，並且Master和Slave的server-id參數值比須要不一致才能使MySQLReplication搭建成功

r/w

client------> master

| REPL (相互)

r/w

client------> master

經過DualMaster 複製架構，咱們不只可以避免由於正常的常規維護操做須要的停機所帶來的從新搭建Replication環境的操做.Dual Master 複製架構和一些第三方的HA管理軟件結合，還能夠在咱們當前正在使用的Master出現異常沒法提供服務以後，很是迅速的自動切換另一端來提供相應的服務，減小異常狀況下帶來的停機時間，而且徹底不須要人工干預。

搭建成一個DualMaster環境，並非爲了讓兩端都提供寫的服務。在正常狀況下，咱們都只會將其中一端開啓寫服務，另一端僅僅只是提供讀服務，或者徹底不提供任何服務，僅僅只是做爲一個備用的機器存在。

級聯複製架構(Master- Slaves - Slaves:

在某些場合讀的壓力特別大,一個master可能須要10臺或者更多的slave才鞥支撐住讀的壓力.這樣的話,master的壓力比較大,由於光是slave的io線程就比較多,這樣寫的壓力稍微大一點,就容易形成複製的延時.

解決==>

以利用MySQL能夠在Slave端記錄複製所產生變動的BinaryLog 信息的功能，也就是打開—log-slave-update選項。而後，經過二級（或者是更多級別）複製來減小Master端由於複製所帶來的壓力。

w repl repl

client--->master -----> slave -----------> slave

| repl

|-->slave ----------> slave

|repl

|------> slave

全部的slave都是對客戶只讀

風險:級聯過多,容易產生延時較長.

dualmaster 與級聯複製結合:

w repl repl

client--->master <------> master ----------> slave

|repl

|-------->slave

|repl

|-------->slave

最大的好處就是既能夠避免主Master的寫入操做不會受到Slave集羣的複製所帶來的影響，同時主Master須要切換的時候也基本上不會出現重搭Replication的狀況.

搭建實現:

1.Master端準備工做

在搭建Replication環境以前，首先要保證Master端MySQL記錄BinaryLog 的選項打開.使用log-bin[=pathfor binary log]參數選項。

還須要準備一個用於複製的MySQL用戶。

mysql>CREATEUSER 'repl'@'192.168.0.2'

->IDENTIFIED BY 'password';

mysql>GRANTREPLICATION SLAVE ON *.*

->TO 'repl'@'192.168.0.2';

2.獲取Master端的備份「快照」

快照:全部數據均是基於某一特定時刻的，數據完整性和一致性均可以獲得保證的備份集.同時還須要取得該備份集時刻所對應的Master端BinaryLog 的準確LogPosition，由於在後面配置Slave的時候會用到

方法:

a)經過數據庫全庫冷備份:

冷備份.

如在Master剛剛啓動以後，尚未應用程序鏈接上Master以前，經過執行SHOWMaster STATUS 命令從Master端獲取到咱們能夠使用的LogPosition。若是咱們沒法在Master啓動以後控制應用程序的鏈接，那麼可能在咱們尚未來得及執行SHOWMaster STATUS 命令以前就已經有數據寫進來了，這時候咱們能夠經過mysqlbinlog客戶端程序分析Master最新的一個BinaryLog 來獲取其第一個有效的LogPosition。

b)經過LVM或者ZFS等具備snapshot功能的軟件進行"熱備份"

文件系統運行在LVM上面，那麼咱們均可以經過相關的命令對MySQL的數據文件和日誌文件所在的目錄就作一個Snapshot，這樣就能夠獲得了一個基本和全庫冷備差很少的備份集。爲了保證咱們的備份集數據可以完整且一致，咱們須要在進行Snapshot過程當中經過相關命令（FLUSHTABLES WITH READ LOCK）來鎖住全部表的寫操做，在作完Snapshot以後，咱們就能夠UNLOCKTABLES 了

由於加了鎖,因此更容易得到logposition : SHOW MASTER STATUS

c)mysqldump 客戶端程序

若是不能停機冷備份,並且也沒有運行在b)上的文件系統,就須要使用mysqldump客戶端程序.

能夠鎖定表(不支持事務,FLUSH TABLES WITH READ LOCK), 或者—single-transaction選項(支持事務)來保持數據的完整性.

得到logposition: 使用mysqldump的 --master-data

d)經過現有某一個Slave端進行「熱備份」

若是如今已經有Slave從咱們須要搭建Replication環境的Master上進行復制的話，那咱們這個備份集就很是容易取得了。。咱們能夠暫時性的停掉現有Slave（若是有多臺則僅僅只須要中止其中的一臺）.同時執行一次FLUSHTABLES 命令來刷新全部表和索引的數據。這時候在該Slave上面就不會再有任何的寫入操做了，咱們既能夠經過copy全部的數據文件和日誌文件來作一個全備份，同時也能夠經過Snapshot（若是支持）來進行備份。

經過現有Slave來獲取備份集的方式，不只僅獲得數據庫備份的方式很簡單，連所須要LogPosition，甚至是新Slave後期的配置等相關動做均可以省略掉，只須要新的Slave徹底基於這個備份集來啓動，就能夠正常從Master進行復制了。

整個過程當中咱們僅僅只是在短暫時間內中止了某臺現有Slave的複製線程，對系統的正常服務影響很小，因此這種方式也基本能夠稱之爲「熱備份」。

3.Slave端恢復"快照"

a)恢復全庫冷備份集

因爲這個備份集是一個完整的數據庫物理備份，咱們僅僅只須要將這個備份集經過FTP或者是SCP之類的網絡傳輸軟件複製到Slave所在的主機，根據Slave上my.cnf配置文件的設置，將文件存放在相應的目錄，覆蓋現有全部的數據和日誌等相關文件，而後再啓動Slave端的MySQL，就完成了整個恢復過程。

b)恢復對Master進行Snapshot獲得的備份集

對於經過對Master進行Snapshot所獲得的備份集，實際上和全庫冷備的恢復方法基本同樣，惟一的差異只是首先須要將該Snapshot經過相應的文件系統mount到某個目錄下，而後才能進行後續的文件拷貝操做。以後的相關操做和恢復全庫冷備份集基本一致，就再也不累述。

c)恢復mysqldump獲得的備份集

經過mysqldump客戶端程序所獲得的備份集，和前面兩種備份集的恢復方式有較大的差異。由於前面兩種備份集的都屬於物理備份，而經過mysqldump客戶端程序所作的備份屬於邏輯備份。恢復mysqldump備份集的方式是經過mysql客戶端程序來執行備份文件中的全部SQL語句。

恢復以前，註銷掉CHANGEMASTER TO 命令部分，

d)恢復經過現有Slave所獲得的熱備份

經過現有Slave所獲得的備份集和上面第一種或者第二種備份集也差很少。若是是經過直接拷貝數據和日誌文件所獲得的備份集，那麼就和全庫冷備同樣的備份方式，若是是經過Snapshot獲得的備份集，就和第二種備份恢復方式徹底一致。

4.配置並啓動Slave:

經過CHANGEMASTER TO 命令來配置而後再啓動Slave

root@localhost: mysql 08:32:38> CHANGE MASTER TO

->MASTER_HOST='192.168.0.1',

->MASTER_USER='repl',

->MASTER_PASSWORD='password',

->MASTER_LOG_FILE='mysql-bin.000035',

->MASTER_LOG_POS=399;

root@localhost: mysql 08:33:49> START SLAVE;

成功!

架構篇（3）讀書筆記

replication的限制:

一旦數據庫過於龐大，尤爲是當寫入過於頻繁，很難由一臺主機支撐的時候，咱們仍是會面臨到擴展瓶頸。

數據切分(sharding):經過某種特定的條件，將咱們存放在同一個數據庫中的數據分散存放到多個數據庫（主機）上面，以達到分散單臺設備負載的效果。。數據的切分同時還能夠提升系統的整體可用性，由於單臺設備Crash以後，只有整體數據的某部分不可用，而不是全部的數據。

數據的切分（Sharding）模式:

一種是按照不一樣的表（或者Schema）來切分到不一樣的數據庫（主機）之上，這種切能夠稱之爲數據的垂直（縱向）切分；

另一種則是根據表中的數據的邏輯關係，將同一個表中的數據按照某種條件拆分到多臺數據庫（主機）上面，這種切分稱之爲數據的水平（橫向）切分。

垂直切分:

一個架構設計較好的應用系統，其整體功能確定是由不少個功能模塊所組成的，而每個功能模塊所須要的數據對應到數據庫中就是一個或者多個表。而在架構設計中，各個功能模塊相互之間的交互點越統一越少，系統的耦合度就越低，系統各個模塊的維護性以及擴展性也就越好。這樣的系統，實現數據的垂直切分也就越容易。

通常來講，若是是一個負載相對不是很大的系統，並且表關聯又很是的頻繁，那可能數據庫讓步，將幾個相關模塊合併在一塊兒減小應用程序的工做的方案能夠減小較多的工做量，這是一個可行的方案。

一個垂直拆分的例子:

1.用戶模塊表：user,user_profile,user_group,user_photo_album

2.羣組討論表：groups,group_message,group_message_content,top_message

3.相冊相關表：photo,photo_album,photo_album_relation,photo_comment

4.事件信息表：event

拆分:

◆羣組討論模塊和用戶模塊之間主要存在經過用戶或者是羣組關係來進行關聯。通常關聯的時候都會是經過用戶的id或者nick_name以及group的id來進行關聯，經過模塊之間的接口實現不會帶來太多麻煩；

◆相冊模塊僅僅與用戶模塊存在經過用戶的關聯。這兩個模塊之間的關聯基本就有經過用戶id關聯的內容，簡單清晰，接口明確；

◆ 事件模塊與各個模塊可能都有關聯，可是都只關注其各個模塊中對象的ID信息，一樣能夠作到很容易分拆。

app====> [users]database

====>[group message]database

====>[photto albums]database

====>[events]database

因此,經過拆分,把之前的一個db存儲這些表,分紅了4個db寫入,這樣就減輕了壓力.

垂直切分的優勢

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

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

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

垂直切分的缺點

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

◆ 對於訪問極其頻繁且數據量超大的表仍然存在性能瓶頸，不必定能知足要求；

◆ 事務處理相對更爲複雜；

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

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

水平切分

將某個訪問極其頻繁的表再按照某個字段的某種規則來分散到多個表之中，每一個表中包含一部分數據。

對於上面的例子:

全部數據都是和用戶關聯的，那麼咱們就能夠根據用戶來進行水平拆分，將不一樣用戶的數據切分到不一樣的數據庫中。

如今互聯網很是火爆的Web2.0類型的網站，基本上大部分數據都可以經過會員用戶信息關聯上，可能不少核心表都很是適合經過會員ID來進行數據的水平切分。而像論壇社區討論系統，就更容易切分了，很是容易按照論壇編號來進行數據的水平切分。切分以後基本上不會出現各個庫之間的交互。

水平切分的優勢

◆ 表關聯基本可以在數據庫端所有完成；

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

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

◆ 事務處理相對簡單；

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

水平切分的缺點

◆ 切分規則相對更爲複雜，很難抽象出一個可以知足整個數據庫的切分規則；

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

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

兩種切分結合用:

通常來講，咱們數據庫中的全部表很難經過某一個（或少數幾個）字段所有關聯起來，因此很難簡單的僅僅經過數據的水平切分來解決全部問題。而垂直切分也只能解決部分問題，對於那些負載很是高的系統，即便僅僅只是單個表都沒法經過單臺數據庫主機來承擔其負載。咱們必須結合「垂直」和「水平」兩種切分方式同時使用

每個應用系統的負載都是一步一步增加上來的，在開始遇到性能瓶頸的時候，大多數架構師和DBA都會選擇先進行數據的垂直拆分，由於這樣的成本最早，最符合這個時期所追求的最大投入產出比。然而，隨着業務的不斷擴張，系統負載的持續增加，在系統穩定一段時期以後，通過了垂直拆分以後的數據庫集羣可能又再一次不堪重負，遇到了性能瓶頸。

==>若是咱們再一次像最開始那樣繼續細分模塊，進行數據的垂直切分，那咱們可能在不久的未來，又會遇到如今所面對的一樣的問題。並且隨着模塊的不斷的細化，應用系統的架構也會愈來愈複雜，整個系統極可能會出現失控的局面。

==>這時候咱們就必需要經過數據的水平切分的優點，來解決這裏所遇到的問題。並且，咱們徹底沒必要要在使用數據水平切分的時候，推倒以前進行數據垂直切分的成果，而是在其基礎上利用水平切分的優點來避開垂直切分的弊端，解決系統複雜性不斷擴大的問題。而水平拆分的弊端（規則難以統一）也已經被以前的垂直切分解決掉了，讓水平拆分能夠進行的駕輕就熟。

示例數據庫:

假設在最開始，咱們進行了數據的垂直切分，然而隨着業務的不斷增加，數據庫系統遇到了瓶頸，咱們選擇重構數據庫集羣的架構。如何重構？考慮到以前已經作好了數據的垂直切分，並且模塊結構清晰明確。而業務增加的勢頭愈來愈猛，即便如今進一步再次拆分模塊，也堅持不了過久。

==>選擇了在垂直切分的基礎上再進行水平拆分。

==>在經歷過垂直拆分後的各個數據庫集羣中的每個都只有一個功能模塊，而每一個功能模塊中的全部表基本上都會與某個字段進行關聯。如用戶模塊所有均可以經過用戶ID進行切分，羣組討論模塊則都經過羣組ID來切分，相冊模塊則根據相冊ID來進切分，最後的事件通知信息表考慮到數據的時限性（僅僅只會訪問最近某個事件段的信息），則考慮按時間來切分。

數據切分以及整合方案.

數據庫中的數據在通過垂直和（或）水平切分被存放在不一樣的數據庫主機以後，應用系統面臨的最大問題就是如何來讓這些數據源獲得較好的整合

存在兩種解決思路：

1.在每一個應用程序模塊中配置管理本身須要的一個（或者多個）數據源，直接訪問各個數據庫，在模塊內完成數據的整合；

2.經過中間代理層來統一管理全部的數據源，後端數據庫集羣對前端應用程序透明；

第二種方案,雖然短時間內須要付出的成本可能會相對更大一些，可是對整個系統的擴展性來講，是很是有幫助的。

針對第二種方案:

1.利用MySQLProxy 實現數據切分及整合.

可用來監視、分析或者傳輸他們之間的通信信息。他的靈活性容許你最大限度的使用它，目前具有的功能主要有鏈接路由，Query分析，Query過濾和修改，負載均衡，以及基本的HA機制等。

MySQLProxy 自己並不具備上述全部的這些功能，而是提供了實現上述功能的基礎。要實現這些功能，還須要經過咱們自行編寫LUA腳原本實現。

原理:

MySQLProxy 其實是在客戶端請求與MySQLServer 之間創建了一個鏈接池。全部客戶端請求都是發向MySQLProxy，而後經由MySQLProxy 進行相應的分析，判斷出是讀操做仍是寫操做，分發至對應的MySQLServer 上。對於多節點Slave集羣，也能夠起作到負載均衡的效果。

2.利用Amoeba實現數據切分及整合

Amoeba是一個基於Java開發的，專一於解決分佈式數據庫數據源整合Proxy程序的開源框架

Amoeba已經具備Query路由，Query過濾，讀寫分離，負載均衡以及HA機制等相關內容。

Amoeba主要解決的如下幾個問題：

a)數據切分後複雜數據源整合；

b)提供數據切分規則並下降數據切分規則給數據庫帶來的影響；

c)下降數據庫與客戶端的鏈接數；

d)讀寫分離路由；

AmoebaFor MySQL 主要是專門針對MySQL數據庫的解決方案，前端應用程序請求的協議以及後端鏈接的數據源數據庫都必須是MySQL。對於客戶端的任何應用程序來講，AmoebaForMySQL 和一個MySQL數據庫沒有什麼區別，任何使用MySQL協議的客戶端請求，均可以被AmoebaFor MySQL 解析並進行相應的處理。

AmoebaFor MySQL 的使用很是簡單，全部的配置文件都是標準的XML文件，總共有四個配置文件。分別爲：

◆ amoeba.xml：主配置文件，配置全部數據源以及Amoeba自身的參數設置；

◆ rule.xml：配置全部Query路由規則的信息；

◆ functionMap.xml：配置用於解析Query中的函數所對應的Java實現類；

◆rullFunctionMap.xml：配置路由規則中須要使用到的特定函數的實現類；

Proxy程序經常使用的功能如讀寫分離，負載均衡等配置都在amoeba.xml中進行。Amoeba已經支持了實現數據的垂直切分和水平切分的自動路由，路由規則能夠在rule.xml進行設置。

3.利用HiveDB實現數據切分及整合

HiveDB一樣是一個基於Java針對MySQL數據庫的提供數據切分及整合的開源框架，只是目前的HiveDB僅僅支持數據的水平切分。主要解決大數據量下數據庫的擴展性及數據的高性能訪問問題，同時支持數據的冗餘及基本的HA機制。

HiveDB的實現機制與MySQLProxy 和Amoeba有必定的差別，他並非藉助MySQL的Replication功能來實現數據的冗餘，而是自行實現了數據冗餘機制，而其底層主要是基於HibernateShards 來實現的數據切分工做。

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

◆ 引入分佈式事務的問題；

◆ 跨節點Join的問題；

◆ 跨節點合併排序分頁問題；

引入分佈式事務的問題?

一旦數據進行切分被分別存放在多個MySQLServer中以後，無論咱們的切分規則設計的多麼的完美（實際上並不存在完美的切分規則），均可能形成以前的某些事務所涉及到的數據已經不在同一個MySQLServer 中了。

==>將一個跨多個數據庫的分佈式事務分拆成多個僅處於單個數據庫上面的小事務，並經過應用程序來總控各個小事務。

跨節點Join的問題?

==>先從一個節點取出數據,而後根據這些數據,再到另外一個表中取數據.

==>使用Federated存儲引擎,問題是:乎若是遠端的表結構發生了變動，本地的表定義信息是不會跟着發生相應變化的。

跨節點合併排序分頁問題?

==>Join自己涉及到的多個表之間的數據讀取通常都會存在一個順序關係。可是排序分頁就不太同樣了，排序分頁的數據源基本上能夠說是一個表（或者一個結果集），自己並不存在一個順序關係，因此在從多個數據源取數據的過程是徹底能夠並行的。這樣，排序分頁數據的取數效率咱們能夠作的比跨庫Join更高，因此帶來的性能損失相對的要更小。

架構篇（4）讀書筆記

分佈式內存Cache軟件Memcached:

1.做爲提高系統性能的Cache工具:

若是咱們將Memcached做爲應用系統的一個數據Cache服務，那麼對於MySQL數據庫來講基本上不用作任何改造，僅僅經過應用程序本身來對這個Cache進行維護更新。這樣做最大的好處就在於能夠作到徹底不用動數據庫相關的架構，可是同時也會有一個弊端，那就是若是須要Cache的數據對象較多的時候，應用程序所須要增長的代碼量就會增長不少，同時系統複雜度以及維護成本也會直線上升。

架構圖:

appserver ---> ds proxy layer ---> db master --> db slave1

| |--> db slave2

|---> memcached1

|---> memcached2

總體來看:

全部數據都會寫入MySQLMaster 中，包括數據第一次寫入時候的INSERT，同時也包括對已有數據的UPDATE和DELETE。

若是是對已經存在的數據，則須要在UPDATE或者DELETEMySQL 中數據的同時，刪除Memcached中的數據，以此保證總體數據的一致性。

全部的讀請求首先會發往Memcached中，若是讀取到數據則直接返回，若是沒有讀取到數據，則再到MySQLSlaves 中讀取數據，並將讀取獲得的數據寫入到Memcached中進行Cache。

這種使用方式通常來講比較適用於須要緩存對象類型少，而須要緩存的數據量又比較大的環境，是一個快速有效的徹底針對性能問題的解決方案。

2.和MySQL整合爲數據服務層

有兩種方式將Memcached和MySQL數據庫整合成一個總體來對外提供數據服務:

直接利用Memcached的內存容量做爲MySQL數據庫的二級緩存，提高MySQLServer的緩存大小，

經過MySQL的UDF來和Memcached進行數據通訊，維護和更新Memcached中的數據，而應用端則直接經過Memcached來讀取數據。

第一種方式，主要用於業務要求很是特殊，實在難以進行數據切分，並且有很難經過對應用程序進行改造利用上數據庫以外的Cache的場景。

==>經過開源項目WaffleGrid實現,將Memcached成功實現成爲MySQL主機的外部「二級緩存」，目前僅支持用於Innodb的BufferPool。

架構圖:

appserver ---> ds proxy layer ---->Waffle Grid --->memcached1

|---> memcached2

|---> memcached3

|---> memcached4

|---> memcached5

這裏面全部的memcached都是innodb的外部bufferpool, 而memcached和mysql之間必定要使用具備高帶寬的私有網絡.

第二種方案:

是經過MySQL所提供的UDF功能，自行編寫相應的程序來實現MySQL與Memcached的數據通訊更新操做。

原理:

這種方式和WaffleGrid 不同的是Memcached中的數據並不徹底由MySQL來控制維護，而是由應用程序和MySQL一塊兒來維護數據。每次應用程序從Memcached讀取數據的時候，若是發現找不到本身須要的數據，則再轉爲從數據庫中讀取數據，而後將讀取到的數據寫入Memcached中。而MySQL則控制Memcached中數據的失效清理工做，每次數據庫中有數據被更新或者被刪除的時候，MySQL則經過用戶自行編寫的UDF(user define unction) 來調用Memcached的API來通知Memcached某些數據已經失效並刪除該數據。

對於使用Memcached等感到成本高,能夠考慮使用BerkeleyDB, TokyoTyrant

使用Search:

使用搜索引擎來提供全文檢索.主要是基於Lucene.

把數據庫的數據經過應用程序調用Lucene的相關API寫入，並利用Lucene建立好索引，而後就能夠經過調用Lucene所提供的數據檢索API獲得須要訪問的數據，並且能夠進行全模糊匹配

雖然Lucene的數據也是存放在磁盤上而不是內存中，可是因爲高效的分詞算法和索引結構，其效率也是很是的好。。看到不少網友在網上討論，當數據量稍微大一些如幾十個G以後Lucene的效率會降低的很是快，其實這是不科學的說法，就從我親眼所見的場景中，就有好幾百G的數據在Lucene中，性能仍然很出色。這幾年性能優化的工做經歷及經驗中我有一個很深的體會，那就是一個軟件性能的好壞，實際上並不只僅只由其自己所決定，不少時候一個很是高效的軟件不一樣的人使用會有大相徑庭效果。因此，不少時候當咱們使用的第三方軟件性能出現問題的時候，不要急着下結論認爲是這個軟件的問題，更多的是先從自身找找看咱們是否真的正確使用了他。

除了使用第三方的Search軟件如Lucene以外，咱們也能夠自行研發更適用於咱們自身應用場景的Search軟件。好比:自行研發了一套純內存存儲的更適合於自身應用場景的高性能分佈式Search軟件

自行實現Cache服務:

若是目前的第三方軟件已經基本解決了咱們系統當前遇到的80%以上的問題，可能就須要考慮是否有必要徹底自主研發了。

利用分佈式用分佈式並行計算實現大數據量的高性能運算:

MapReduce(任務分解和任務合併功能)+ HDFS(分佈式文件系統)+ Hbase(高性能的分佈式數據庫)

架構篇（5）讀書筆記

任何設備（或服務），只要是單點，就存在着很大的安全隱患。由於一旦這臺設備（或服務）crash以後，在短期內就很難有備用設備（或服務）來頂替其功能。因此稍微重要一些的服務器或者應用系統，都會存在至少一個備份以供出現異常的時候可以很快的頂替上來提供服務。

對於數據庫來講，主備配置是很是常見的設計思路。而對於MySQL來講，其Replication功能在實際應用中被普遍的用來實現主備配置的功能。

常規的Master- Slave 解決基本的主備設計:

在普通的一個Master後面複製一個或者多個Slave的架構設計中，當咱們的某一臺Slave出現故障不能提供服務以後，咱們還有至少一臺MySQL服務器（Master）能夠提供服務，不至於全部和數據庫相關的業務都不能運行下去。若是Slave超過一臺，那麼剩下的Slave也仍然可以不受任何干擾的繼續提供服務。

這種架構方式很容易解決Slave出現故障的狀況，並且不須要進行任何調整就能繼續提供服務。

Master單點問題的解決:

兩種解決方案:

a)將Slave中的某一臺切換成Master對外提供服務，同時將其餘全部的Slave都以經過CHANGEMASTER 命令來將經過新的Master進行復制。

b)新增一臺Master，也就是DualMaster 的解決方案。

c)方案最大的一個弊端就是切換步驟比較多，實現比較複雜。並且，在Master出現故障crash的那個時刻，咱們的全部Slave的複製進度並不必定徹底一致，有可能有少許的差別。這時候，選擇哪個Slave做爲Master也是一個比較頭疼的問題。因此這個方案的可控性並非特別的高。

b)方案實際上就是經過DualMaster 來解決Master單點問題

經過兩臺MySQLServer 搭建成DualMaster 環境，正常狀況下，全部客戶端的Write請求都寫往MasterA，而後經過Replication將MasterA 複製到MasterB。一旦MasterA 出現問題以後，全部的Write請求都轉向MasterB。而在正常狀況下，當MasterB 出現問題的時候，實際上不管是數據庫仍是客戶端的請求，都不會受到實質性的影響。

當咱們的MasterA 出現問題的時候，應用如何作到自動將請求轉向到MasterB 呢？

==>只須要經過相應的硬件設備如F5或者Cluster管理軟件如Heartbeat來設置一個VIP，正常狀況下該VIP指向MasterA，而一旦MasterA 出現異常crash以後，則自動切換指向到MasterB，前端所的應用都經過這個VIP來訪問Master。

DualMaster 與級聯複製結合解決異常故障下的高可用:

經過前面的架構分析，咱們分別獲得了Slave出現故障後的解決方案，也解決了Master的單點問題。如今咱們再經過DualMaster 與級聯複製結合的架構，來獲得一個總體的解決方案，解決系統總體可靠性的問題。

首先考慮Slave出現異常的狀況。

在這個架構中，Slave出現異常後的處理狀況和普通的Master- Slave 架構的處理方式徹底同樣，僅僅須要在應用訪問Slave集羣的訪問配置中去掉一個Slave節點便可解決，不管是經過應用程序本身判斷，仍是經過硬件解決方案如F5均可以很容易的實現。

當MasterA 出現故障crash以後，MasterA 與MasterB 之間的複製將中斷，全部客戶端向MasterA 的Write請求都必須轉向MasterB。這個轉向動做的實現，能夠經過上面介紹的第二中方案中所介紹的經過VIP的方式實現。因爲以前全部的Slave就都是從MasterB 來實現複製，因此Slave集羣不會受到任何的影響，客戶端的全部Read請求也就不會受到任何的影響，整個過程能夠徹底自動進行，不須要任何的人爲干預。不過這裏有一個隱患就是當MasterA crash 的時候若是MasterB 做爲Slave的IO線程若是尚未讀取完MasterA 的二進制日誌的話，就會出現數據丟失的問題。要徹底解決這個問題，咱們只能經過第三方patch（google開發）來鏡像MySQL的二進制日誌到MasterB上面，才能徹底避免不丟失任何數據。

那麼當MasterB 出現故障crash以後的狀況又如何呢？

首先能夠肯定的是咱們的全部Write請求都不會受到任何影響，並且全部的Read請求也都仍是可以正常訪問。但全部Slave的複製都會中斷，Slave上面的數據會開始出現滯後的現象。這時候咱們須要作的就是將全部的Slave進行CHANGEMASTER TO 操做，改成從MasterA 進行復制。因爲全部Slave的複製都不可能超前最初的數據源，因此能夠根據Slave上面的RelayLog中的時間戳信息與MasterA 中的時間戳信息進行對照來找到準確的複製起始點，不會形成任何的數據丟失。

DualMaster 與級聯複製結合解決在線DDL變動問題:

使用DualMaster 加級聯複製的組合架構的時候，對於MySQL的一個致命傷也就是在線DDL變動來講，也能夠獲得必定的解決。如當咱們須要給某個表tab增長一個字段，能夠經過以下在上述架構中來實現：

一、在Slave集羣中抽出一臺暫時中止提供服務，而後對其進行變動，完成後再放回集羣繼續提供服務；

二、重複第一步的操做完成全部Slave的變動；

三、暫停MasterB 的複製，同時關閉當前session記錄二進制日誌的功能，對其進行變動，完成後再啓動複製；

四、經過VIP切換，將應用全部對MasterA 的請求切換至MasterB；

五、關閉MasterA 當前session記錄二進制日誌的功能，而後進行變動；

六、最後再將VIP從MasterB 切換回MasterA，至此，全部變動完成。

變動過程當中有幾點須要注意的：

一、整個Slave集羣須要可以承受在少一臺MySQL的時候仍然可以支撐全部業務；

二、Slave集羣中增長或者減小一臺MySQL的操做簡單，可經過在線調整應用配置來實現；

三、DualMaster 之間的VIP切換簡單，且切換時間較短，由於這個切換過程會形成短期段內應用沒法訪問Master數據庫。

四、在變動MasterB 的時候，會出現短期段內Slave集羣數據的延時，因此若是單臺主機的變動時間較長的話，須要在業務量較低的凌晨進行變動。若是有必要，甚至可能須要變動MasterB 以前將全部Slave切換爲以MasterB 做爲Master。

使用DRBD保證數據的高可靠:

在MySQL的官方文檔手冊的HighAvailability and Scalability 這一章中將DRBD做爲MySQL實現高可用性的一個很是重要的方式來介紹的。

DRBD其實就是經過網絡來實現塊設備的數據鏡像同步的一款開源Cluster軟件，也被俗稱爲網絡RAID1。

DRBD介於文件系統與磁盤介質之間，經過捕獲上層文件系統的全部IO操做，而後調用內核中的IO模塊來讀寫底層的磁盤介質。當DRBD捕獲到文件系統的寫操做以後，會在進行本地的磁盤寫操做的同時，以TCP/IP協議將，經過本地主機的網絡設備（NIC）將IO傳遞至遠程主機的網絡設備。當遠程主機的DRBD監聽到傳遞過來的IO信息以後，會當即將該數據寫入到該DRBD所維護的磁盤設備。至此，整個IO才作完成。

DRBD在處理遠程數據寫入的時候有三種複製模式（或者稱爲級別）能夠選擇，不一樣的複製模式保證了遠程數據寫入的三種可靠性。三種級別的選擇能夠經過DRBD的通用配置部分的protocal。不一樣的複製模式，其實是影響了一個IO完成所表明的實際含義。由於當咱們使用DRBD的時候，一個IO完成的標識（DRBD返回IO完成）是本地寫入和遠程寫入這兩個併發進程都返回完成標識。下面我來詳細介紹一下這三種複製模式所表明的含義：

ProtocolA：這種模式是可靠性最低的模式，並且是一個異步的模式。當咱們使用這個模式來配置的時候，寫遠程數據的進程將數據經過TCP/IP協議發送進入本地主機的TCPsendbuffer 中，即返回完成。

ProtocolB：這種模式相對於ProtocolA 來講，可靠性要更高一些。由於寫入遠程的線程會等待網絡信息傳輸完成，也就是數據已經被遠程的DRBD接受到以後返回完成。

ProtocolC：ProtocolC 複製模式是真正徹底的同步複製模式，只有當遠程的DRBD將數據徹底寫入磁盤成功後，纔會返回完成。

其餘高可用方案:

RaiDB:其全稱爲RedundantArrays of Inexpensive Databases。也就是經過Raid理念來管理數據庫的數據

raiddb-0:

sqlrequest --> raidb controller --> table 1

--> table 2

--> table 3

raiddb-1:

sqlrequest --> raidb controller --> db full

--> db full

raiddb-2:

sqlrequest --> raidb controller --> db full

--> table 1

--> table 2

raiddb-0-1:

sqlrequest --> raidb controller 0 --->raidb-1 controler -->table1

--> table1

--->raidb-1 controler --> table2

--> table2

--->raidb-1 controler --> table3

--> table3

raiddb-1-0:

sqlrequest --> raidb controller 1 --> raidb controller 0 -->table 1

--> table 2

--> table 3

--> raidb controller 0 --> table 1

--> table 2

--> table 3

--> raidb controller 0 --> table 1

--> table 2

--> table 3

方案比較:

一、MySQLReplication

優點：部署簡單，實施方便，維護也不復雜，是MySQL天生就支持的功能。且主備機之間切換方便，能夠經過第三方軟件或者自行編寫簡單的腳本便可自動完成主備切換。

劣勢：若是Master主機硬件故障且沒法恢復，則可能形成部分未傳送到Slave端的數據丟失；

二、MySQLCluster

優點：可用性很是高，性能很是好。每一分數據至少在不一樣主機上面存在一份拷貝，且冗餘數據拷貝實時同步。

劣勢：維護較爲複雜，產品還比較新，存在部分bug，目前還不必定適用於比較核心的線上系統。

三、DRBD磁盤網絡鏡像方案

優點：軟件功能強大，數據在底層快設備級別跨物理主機鏡像，且可根據性能和可靠性要求配置不一樣級別的同步。IO操做保持順序，可知足數據庫對數據一致性的苛刻要求。

劣勢：非分佈式文件系統環境沒法支持鏡像數據同時可見，性能和可靠性二者相互矛盾，沒法適用於性能和可靠性要求都比較苛刻的環境。維護成本高於MySQLReplication。

一個通過高可用可擴展設計的MySQL數據庫集羣，若是沒有一個足夠精細足夠強大的監控系統，一樣可能會讓以前在高可用設計方面所作的努力功虧一簣。

MySQL分佈式集羣的監控系統總體架構體系:

mysqldb--->|

mysqldb--->| |-->報警

mysqldb--->|---->信息採集 --->信息存儲 --->|-->狀態

mysqldb--->| |-->趨勢

mysqldb--->|

信息採集:

通常來講，較小規模的監控點能夠採用輪詢的方式主動採集數據，可是當監控點達到必定規模之後，輪詢的主動採集方式可能就會遇到必定的性能瓶頸和信息延時問題，尤爲是當須要採集的數據比較多的時候尤其突出。而若是要採用從各個MySQL節點進行被動的推送，則可能須要開發可以支持網絡通訊的監控程序，使採集的信息可以順利的到達信息分析模塊以即時獲得分析，成本會稍微高一些。

不管是採用主動仍是被動的方式來進行數據採集，咱們都須要在監控主機上面部署採集相關信息的程序或腳本，包括主機信息和數據庫信息。

主機健康狀態監控:

●網絡通訊：網絡通訊基本上能夠說是最容易檢測的了，基本上只須要經過網絡ping就能夠獲知是否正常。

●系統軟硬件錯誤：系統軟硬件錯誤，通常使用文本監控軟件，如sec、logwatch等日誌監控專用軟件，經過配置相應的匹配規則，從日誌文件中捕獲知足條件的錯誤信息，再發送給信息分析模塊。

● 磁盤空間：對於磁盤空間的使用情況監控，咱們經過最簡單的shell腳本就能夠輕鬆搞定

●內存使用：系統物理內存使用量的信息採集一樣很是簡單，只須要一個基本的系統命令「free」，就能夠得到當前系統內存總量，剩餘使用量，以及文件系統的buffer和cache二者使用量。

●進程數量：系統進程總數，或者某個用戶下的進程數，均可以經過「ps」命令通過簡單的處理來得到。

數據庫健康狀態信息

服務端口（3306）服務端口狀態的監控和主機網絡鏈接的監控一樣很是簡單，只須要對3306端口進行telnet嘗試便可。

mysqld和mysqld_safe進程：mysqld進程是MySQLServer 最核心的進程。mysqld進程crash或者出現異常，MySQLServer 基本上也就沒法正常提供服務了。固然，若是咱們是經過mysqld_safe來啓動MySQLServer，則mysqld_safe會幫助咱們來監控mysqld進程的狀態，當mysqld進程crash以後，mysqld_safe會立刻幫助咱們重啓mysqld進程。

Errorlog：Errorlog 的監控目的主要是即時檢測MySQLServer 運行過程當中發生的各類錯誤，如鏈接異常，系統bug等。

複製狀態：若是咱們的MySQL數據庫環境使用了MySQLReplication，就必須增長對Slave複製狀態的監控。對Slave的複製狀態的監控包括對IO線程和SQL線程兩者的運行狀態的監控。固然，若是但願可以監控Replication更多的信息，如兩個線程各自運行的進度等，一樣能夠在Slave節點上執行相應命令輕鬆獲得

sky@localhost: (none) 04:30:38> show slave status\G

性能狀態監控:

系統load值：系統load所包含的最關鍵含義是CPU運行等待的數量，

sky@sky:~$uptime

17:27:44up 4:12, 3 users, load average: 0.87, 0.66, 0.61

「loadaverage: 0.87, 0.66, 0.61」中的三個數字，分別表明了1秒、5秒和15秒的load平均值。

CPU使用率:最爲經常使用的方法是使用命令top和vmstat來獲取。

磁盤IO量：能夠經過vmstat, iostat來獲取

swap進出量:swap 的使用主要表現了系統在物理內存不夠的狀況下使用虛擬內存的狀況。

free命令只能得到當前系統swap的整體使用量。若是但願得到實時的swap使用變化，仍是得依賴vmstat來獲得

網絡流量：第三方軟件如ifstat、iftop和nload

數據庫性能狀態:

MySQL數據庫的性能狀態監控點很是之多，其中不少量都是咱們不能忽視的必須監控的量，且90%以上的內容能夠在鏈接上MySQLServer 後執行「SHOW/*!50000 GLOBAL */STATUS」以及「SHOW/*!50000 GLOBAL */ VARIABLES」的輸出值得到。須要注意的是上述命令所得到狀態值其實是累計值，因此若是要計算(單位/某個)時間段內的變化量還須要稍加處理，能夠在附錄中找到兩個命令輸出值的詳細說明。下面看看幾項須要重點關注的性能狀態：

QPS（每秒Query量）：

QPS= Questions(or Queries) / Seconds

獲取所需狀態變量值：

SHOW/*!50000 GLOBAL */ STATUS LIKE 'Questions'

SHOW/*!50000 GLOBAL */ STATUS LIKE 'Queries'

TPS（每秒事務量）：在MySQLServer 中並無直接事務計數器，咱們只能經過回滾和提交計數器來計算出系統的事務量。

TPS= (Com_commit + Com_rollback) / Seconds

KeyBuffer 命中率：KeyBuffer 命中率表明了MyISAM類型表的索引的Cache命中率。該命中率的大小將直接影響MyISAM類型表的讀寫性能。

key_buffer_read_hits= (1 - Key_reads / Key_read_requests) * 100%

key_buffer_write_hits=(1 - Key_writes / Key_write_requests) * 100%

mysq>SHOW/*!50000 GLOBAL */ STATUS

->LIKE 'Key%';

-----------------------------------

|Key_read_requests | 10 |

|Key_reads | 4 |

|Key_write_requests | 0 |

|Key_writes | 0 |

+------------------------+-------+

InnodbBuffer 命中率:

這裏InnodbBuffer 所指的是innodb_buffer_pool，也就是用來緩存Innodb類型表的數據和索引的內存空間。

innodb_buffer_read_hits=(1-Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests)* 100%

mysql> SHOW /*!50000 GLOBAL*/ STATUS

->LIKE 'Innodb_buffer_pool_read%';

|Innodb_buffer_pool_read_requests | 5367 |

|Innodb_buffer_pool_reads | 507 |

+-----------------------------------+-------+

QueryCache 命中率：

Query_cache_hits=(Qcache_hits / (Qcache_hits + Qcache_inserts)) * 100%

mysql> SHOW /*!50000 GLOBAL*/ STATUS

->LIKE 'Qcache%';

|Qcache_hits | 0 |

|Qcache_inserts | 0 |

TableCache 狀態量:

判斷系統參數table_open_cache的設置是否合理。Open_tables與Opened_tables之間的比率太低，則表明TableCache 設置太小，我的認爲該值處於80%左右比較合適。

mysql>SHOW /*!50000 GLOBAL*/ STATUS

->LIKE 'Open%';

|Open_tables | 51 |

Opened_tables| 61 |

ThreadCache 命中率：

ThreadCache 命中率可以直接反應出咱們的系統參數thread_cache_size設置的是否合理.一個合理的thread_cache_size參數可以節約大量建立新鏈接時所須要消耗的資源。

Thread_cache_hits= (1 - Threads_created / Connections) * 100%

mysql> SHOW /*!50000 GLOBAL*/ STATUS

->LIKE 'Thread%';

|Threads_created | 3 |

mysql> SHOW /*!50000 GLOBAL*/ STATUS

->LIKE 'Connections';

Connections| 11 |

鎖定狀態：鎖定狀態包括表鎖和行鎖兩種

mysql> SHOW /*!50000 GLOBAL*/ STATUS

->LIKE '%lock%';

|Innodb_row_lock_current_waits | 0 |

|Innodb_row_lock_time | 0 |

|Innodb_row_lock_time_avg | 0 |

|Innodb_row_lock_time_max | 0 |

|Innodb_row_lock_waits | 0 |

|Table_locks_immediate | 44 |

|Table_locks_waited | 0 |

如當Table_locks_waited與Table_locks_immediate的比值較大，則說明咱們的表鎖形成的阻塞比較嚴重

Innodb_row_lock_waits較大，則說明Innodb的行鎖也比較嚴重，且影響了其餘線程的正常處理

複製延時量：複製延時量將直接影響了Slave數據庫處於不一致狀態的時間長短。若是咱們是經過Slave來提供讀服務，就不得不重視這個延時量。能夠經過在Slave節點上執行「SHOWSLAVE STATUS」命令，取Seconds_Behind_Master項的值來了解Slave當前的延時量（單位：秒）

Tmptable 情況：

TmpTable 的情況主要是用於監控MySQL使用臨時表的量是否過多，是否有臨時表過大而不得不從內存中換出到磁盤文件上。

mysql> SHOW /*!50000 GLOBAL*/ STATUS

->LIKE 'Created_tmp%';

Created_tmp_disk_tables| 1 |

Created_tmp_tables | 46 |

從上面能夠看出系統使用了46次臨時表，其中有1次臨時表比較大，沒法在內存中完成，而不得不使用到磁盤文件

BinlogCache 使用情況：BinlogCache 用於存放還未寫入磁盤的Binlog信息。

mysql> SHOW /*!50000 GLOBAL*/ STATUS

->LIKE 'Binlog_cache%';

|Binlog_cache_disk_use | 0 |

|Binlog_cache_use | 0 |