埋在MYSQL數(shù)據(jù)庫應用的關鍵問題有哪些

埋在MYSQL數(shù)據(jù)庫應用的關鍵問題有哪些，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

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

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

一、單Master

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

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

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

恢復：把文件copy到對應目錄。

2）熱備： Ibbackup或者XtraBackup工具，記錄重做日志文件檢查點的LSN，copy共享表空間文件以及獨立表空間文件（不產(chǎn)生任何阻塞），記錄copy后重做日志文件檢查點的LSN，copy備份是產(chǎn)生的重做日志。

恢復：恢復表空間文件，應用重做日志文件。

3）溫備：

• mysqldump，--single-transaction參數(shù)進行事務管理保證數(shù)據(jù)一致性。備份時不能用DDL語句。 恢復：直接執(zhí)行文件，mysql –uroot –p <文件名.sql>

• 二進制半同步復制，主從服務器增量復制

恢復：mysqlbinlog

二、一主一從

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

讀寫分離和負載均衡的實現(xiàn)相對簡單些，我目前維護的系統(tǒng)比較落后，沒有做讀寫分離，因為是一套以報表類功能為主的系統(tǒng)，而負載均衡是依賴php代碼來做的，從實際運維效果來看，不大理想，而且負載均衡的代碼過分嵌入到業(yè)務邏輯代碼中，給代碼維護帶來一定噪音。下學期計劃對各種中間件進行實踐和性能測試，到時候把一些測試數(shù)據(jù)分享出來。

三、一主 n 從

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

四、橫向集群

系統(tǒng)龐大到需要分庫分表，其實是一件可喜可賀的事情，但是切記的是要前面提到性能優(yōu)化工作做到極致之后才好考慮這些會增加系統(tǒng)復雜度的解決方案。橫向集群主要是從業(yè)務特性的角度對系統(tǒng)進行切分，最徹底就是切分成了各個子系統(tǒng)，子系統(tǒng)之間通過一些數(shù)據(jù)同步的方案來把一些核心數(shù)據(jù)進行共享，以避免跨庫調(diào)用跨庫join。

然后是各種系統(tǒng)接口調(diào)用，把大事務拆成小事務，事務之間做好隔離和同步。上圖中的三個問題在橫向集群的架構體系中應屬于很有特色的問題，在實際項目中其實是盡量去避免這些需求的存在的，不過如果確實需要了，也得有解決方案。下學期也將針對這些問題進行逐一整理，并測試一下一些號稱支持這些功能的中間件。

五、縱向集群

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

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

六、混合模式

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

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業(yè)資訊頻道，感謝您對億速云的支持。