原文：

Mysql的使用非常普遍，跟mysql有關的話題也非常多，如效能最佳化、高可用性、強一致性、安全、備份、叢集、橫向擴充套件、縱向擴充套件、負載均衡、讀寫分離等。要想掌握其中的精髓，可得花費不少功力，雖然目前流行的mysql替代方案有很多，可是從最小成本最容易維護的角度而言，mysql還是首選。下面從應用場景的角度切入，對mysql的技術點進行組織，寫一份知識圖譜，方便進行更深入的學習和總結。

如下圖整理，我試著把Mysql的應用場景分為6種，每種場景下需要考慮的重點問題不一樣，從而引出不同問題點下需要補齊的知識點，後續繼續基於這些知識點進行學習和整理。（期待大家的意見和提供學習材料，謝謝！）

一、單Master

單Master的情況是普遍存在的，對於很多個人站點、初創公司、小型內部系統，考慮到成本、更新頻率、系統重要性等問題，系統只依賴一個單例資料庫提供服務，基本上已經滿足需求。這種場景下我覺得重點應該關注的話題有上圖所示的四點。

其中最重要的環節是資料備份，如果是交易量非常低，並且具有非常明確的服務時間段特性的話，簡單的mysqldump是可以勝任的。但是這是有缺陷的，資料還原之後註定從備份點到還原點之間的資料會丟失。然而在極多數的情況下，備份的工作是沒法馬虎的，如下列舉的幾點小細節，下學期將分享更多操作性的文章。

1）冷備：停機，直接copy物理檔案，InnoDB引擎（frm檔案、共享表空間檔案、獨立表空間檔案、重做日誌檔案、my.cnf）。

恢復：把檔案copy到對應目錄。

2）熱備： Ibbackup或者XtraBackup工具，記錄重做日誌檔案檢查點的LSN，copy共享表空間檔案以及獨立表空間檔案（不產生任何阻塞），記錄copy後重做日誌檔案檢查點的LSN，copy備份是產生的重做日誌。

恢復：恢復表空間檔案，應用重做日誌檔案。

3）溫備：

• mysqldump，--single-transaction引數進行事務管理保證資料一致性。備份時不能用DDL語句。 恢復：直接執行檔案，mysql –uroot –p

• 二進位制半同步複製，主從伺服器增量複製

恢復：mysqlbinlog

二、一主一從

考慮一主一從的多數初衷是系統效能和系統高可用性問題，除了單Master場景中的備份工作需要做好以外，還有效能最佳化、讀寫分離、負載均衡三項重點工作需要考慮。其中效能最佳化的內容比較多，也是一塊大主題，要從系統的服務指標作為依據採取相應的動作，多數系統要求的是3秒內完成請求，總體換算下來，資料庫大概可以有1.5秒的總執行時間，能滿足這個效能要求就是合理的最佳化方案。下學期以這樣的優先順序來分別整理內容：索引最佳化 -》 表設計最佳化 -》資料庫配置最佳化 -》硬體最佳化。

讀寫分離和負載均衡的實現相對簡單些，我目前維護的系統比較落後，沒有做讀寫分離，因為是一套以報表類功能為主的系統，而負載均衡是依賴php程式碼來做的，從實際運維效果來看，不大理想，而且負載均衡的程式碼過分嵌入到業務邏輯程式碼中，給程式碼維護帶來一定噪音。下學期計劃對各種中介軟體進行實踐和效能測試，到時候把一些測試資料分享出來。

三、一主 n 從

一旦開始考慮一主多從的伺服器架構，則證明你的系統對可用性、一致性、效能中一種或者多種的要求比較高。好多系統在開始搭建的時候都會往這個方向看齊，畢竟這樣“看起來”系統會健壯很多。不過其實並不能單單依靠mysql的配置和mysql自帶的中介軟體來解決可用性、一致性方面的問題。

四、橫向叢集

系統龐大到需要分庫分表，其實是一件可喜可賀的事情，但是切記的是要前面提到效能最佳化工作做到極致之後才好考慮這些會增加系統複雜度的解決方案。橫向叢集主要是從業務特性的角度對系統進行切分，最徹底就是切分成了各個子系統，子系統之間透過一些資料同步的方案來把一些核心資料進行共享，以避免跨庫呼叫跨庫join。

然後是各種系統介面呼叫，把大事務拆成小事務，事務之間做好隔離和同步。上圖中的三個問題在橫向叢集的架構體系中應屬於很有特色的問題，在實際專案中其實是儘量去避免這些需求的存在的，不過如果確實需要了，也得有解決方案。下學期也將針對這些問題進行逐一整理，並測試一下一些號稱支援這些功能的中介軟體。

五、縱向叢集

橫向叢集的切分思路最終是切分子系統，而縱向叢集最後遇到的最棘手的問題是擴縮容，我運維的一個系統是提前對資料做了256個切片，256切片中0~127切片和128~255切片分別存在兩個一主兩從的資料庫叢集中，系統運維了3年多，目前還沒有擴容需求。設計初衷應該是考慮得到，假設有一天資料量非常大，可以把256個切片分4大片，分別儲存到4個一主兩從的叢集中，從而實現擴容。

這個思路的確是可取的，只是我們的分庫邏輯當前是php程式碼實現，也有一定程度上影響了業務程式碼的邏輯，運維起來有點心驚膽戰，還是保持業務程式碼清爽比較好。

下學期將介紹一些實現了庫路由功能的中介軟體的使用，也根據實際情況把想到的一些擴縮容方案實踐一遍，敬請期待實操效果的分享。

六、混合模式

與其說這部分內容討論上面5種場景的混合，不如說這部分內容是做總結。上面的5種場景中，一共列舉了17個問題點，這17個問題點基本上都是疊加式的，越往深入的框架去做就越需要考慮齊這17個問題點。17個問題點考慮全了，混合模式下的問題就不成問題了。