本文作者將站在更加全面的角度分享他在這一年多 DBA 工作中的經驗，希望可以給大家帶來啟發和幫助。

DBA 的日常工作

我覺得 DBA 真的很忙，我們來看看 DBA 的具體工作：備份和恢復、監控狀態、集群搭建與擴容、數據遷移和高可用。

上面這些是我們 DBA 的功能，了解這些功能以后要對體系結構有更加深入的了解，你不知道怎么處理這些故障和投訴的事情。

所以我們要去了解緩存/線程、SQL 優化、存儲引擎、SQL 審計以及鎖與實務；體系結構更深一點，就去研究內核原理和源碼定制。

DBA 有這么多工作，它們就像一個小怪獸一樣等著我們去解決。

MySQL 的性能優化

性能優化讓我們的 MySQL 跑的更快、更順暢。在我們開始 MySQL 性能優化之前，我想提出 MySQL 性能優化的三個關鍵點：Why？What？How？

為什么我們要做性能優化？我們的運維來反映我們的數據庫，正常情況下是 1 秒，后來變成 10 秒，我們就要啟動優化的動作。原本他的訪問時間是 1 秒，我們想優化成 0.01 秒就要開啟優化。

第二就是 What？哪里是導致我們數據庫性能變差的原因，需要找到這個關鍵點。

當我們找到這個問題以后，我們就需要有的放矢地進行優化。MySQL 優化之前我們要明確 3W 關鍵點。

MySQL 優化基本流程

對于開展 MySQL 優化一個基本的流程如下：我們首先要登陸到操作系統，通過操作系統的命令進行優化。

比如說通過操作系統的基本命令，去看我們操作系統有什么資源的占用率比較高。

就是哪里出現了資源短板，短板的意思就是這個資源的占用率或者是使用率特別高，我們要密切關注。

比如說像 CPU 的負載特別高，已經超過了我們的核數，或者是使用率特別高，已經達到了 80% 以上，這就引起我們的關注了。

確定這個短板之后，我們就要確認哪個進程使用我們這個資源，使得它的使用率或者是占用率特別高。

一般情況下跟我們相關的就是 MySQL 這一層，比方說使用 CPU 的 70% 以上，我們就要去檢查一下這個 MySQL 出現了什么問題。

再進一步往里推進，如果我們發現 MySQL 里面是執行某一條大 MySQL 的時候，發現整個服務器或者是整個數據庫就在那里，可能就是語句問題。

我們就要進一步通過 MySQL 的監控或者是日志信息去排查 MySQL 的問題，很重要的是發現哪個資源出現問題進行排查。

我們登陸系統發現 CPU、IO、網絡等等都很正常，這種情況下怎么辦？

這種情況下我們可以分三種情況判斷：

• 操作系統的問題，可能我們登陸 MySQL 的時候整個系統就在那里了，我們需要通過操作系統去查是哪個資源的問題。
• 數據庫實例問題，數據庫實例問題跟數據庫配置參數相關，也就是說我們配置參數可能存在一些不合理的設置需要我們去優化。
• 會話問題，我們登陸到 MySQL 里面，一開始很正常，后來我們發現這個實例慢下來了，可能就是 MySQL 語句有問題，我們需要看 MySQL 的執行計劃到具體哪一步比較慢，拖慢了整個流程。

我們發現數據庫性能出現問題，都可以沿著這個流程走下去，從而定位出問題。

MySQL 優化的幾個關鍵點

我們通過剛才的基本流程，可以確定出 MySQL 需要優化的幾個關鍵點如下：

• 應用訪問的優化，因為有應用需要訪問我們的數據庫，有請求的發送、數據的存儲和網絡的交互等等，會導致數據庫性能發生比較慢的地方。
• 服務器硬件選型，不知道大家 DBA 對服務器有沒有自主權，如果有自主權的情況下，我覺得我們應該按照 MySQL 的特性來選擇服務器的硬件。

比方說我們可能要考慮到數據和日志的存儲機理不同，要選擇不同的類型去優化它。

• 操作系統的優化，就是我們部署配置數據庫之前，要對操作系統有什么優化？能夠讓我們的數據庫有優化。
• 數據庫優化，數據庫優化過程是一個全局角度優化的過程，不僅僅是是針對數據庫本身優化的流程。

應用訪問優化

我們根據每個關鍵點稍微開展一下，比方說應用訪問的優化。

首先***步就是減少數據的訪問。因為減少數據的訪問其實就是減少磁盤的訪問。

我們知道數據訪問磁盤獲得數據的速度很慢，如果我們是器械磁盤，因為器械磁盤是通過器械旋轉來獲得數據。

我們應該把活躍數據和內存數據放在內存里面，這樣可以使我們的數據庫性能提升 1-1000 倍，它的優化成本很低。

第二步是減少返回更多的數據，減少返回更多的數據終結就是減少了網絡的傳輸，有很多大的系統，網絡傳輸是一個很重要的瓶頸。

假設我們的數據庫服務器跟我們應用服務器的距離是 20 公里的話，因為光線數據庫是 20 公里，一個光的請求是 0.2 毫秒。如果我們減少更少的數據請求的話，那這個時間就會變短很多。

所以說如果我們發現數據庫的性能有問題，我們可以去看是否網絡上存在問題或者是通過 P 命令看時間是否會變得長。

第三是減少交互次數，每個交互假設還是按照 20 公里來說，一個交互的時間就是 0.2 毫秒，2 個交互就是 0.4 毫秒。如果有 1 萬個操作的話，就是 1 萬乘 0.4 毫秒，那就變得整個交互時間變短了很多。

但是也有它的復雜性或者是不宜擴展的局面。從應用層就降低了優化。這個成本也是很低的。

我們公司的 DBA 對于服務器的應用選型沒有太多的話語權，移動公司都是集團公司通過集采來選擇的。

在采集的時候我們不可能規定這幾臺服務器是用在哪個數據庫，這幾個數據庫用在什么服務系統。所以我們在服務器選型時候 DBA 是沒有辦法參與進去的。

這是我們移動云的一些服務器的選型：采用的服務器是惠普的 DL360G9，CPU是 2 核×e5-2650V4，內存是 8×32G，硬盤是 6×1.2TSAS，網卡是 4×10GE+4×1GE+1IPMI。

這里特別說一下，如果我們 DBA 對于服務器有自主權的話，我們可以把數據放到 SSD 盤，把日志放到 SAS 上，這就是服務器硬件選型需要主要的地方。

操作系統層面的優化

我們推薦使用 Linux 操作系統，一些開源主流的是我們做的。像一些商業版 Linux 這些就是我們在用的。

如果要使用這個 SWAP 值，我們盡量不去使用虛擬內存，而使用物理內存。因為物理內存的訪問速度肯定比去訪問磁盤要快得多。

所以我們把這個值設成了 10。有的同學可能就會說為什么不把這個值設成 0，就直接全部訪問物理內存就好了。

如果把它設為 0 的話，可能就會出現內存溢出的現象，就是 OOM。這不是我們 DBA 想看到的情況，所以我們一般把這個值設成 10。

關閉 NUMA 特性：我們公司一般是單實例的情況，所以這個時候 NUMA 的特性要關注。

NUMA 特性就是假設我們一個服務器上有兩個 CPU，分布在服務器左右兩邊，同時有四塊內存，把同一側 CPU 作為一個 NUMA 節點，就是在物理位置分布同一側 CPU 訪問同一側內存，距離比較近，速度更快。

我們盡量同一側 CPU 訪問同一側內存，這跟我們數據庫的特性是相違背的。因為我們數據庫希望它一般部署了數據庫的服務器就不會布其他的應用系統資源了。

所以我們希望數據庫是獨占數據庫資源，在這種情況下我們要盡量關閉這個 NUMA 特性。

網卡優化：我們采用多個物理網卡通過做 Bond 綁定成虛擬網卡，就是一些雙網卡做成 Bond 或者調整網絡參數。

磁盤調度設置：一般會有幾個算法，如 NOOP 算法、CFQ 或者是 Deadline 算法。

比如說這 NOOP 算法用在我們數據庫上有什么問題？就會有餓死讀操作的方式存在，如果兩個寫操作，***個寫操作進來不需要等這個結束以后第二個寫操作就可以開展了。

如果是讀操作的話，第二個讀操作就一定要在在前一個完成。如果有幾毫秒的時間里面，進來一堆寫操作，后面的讀操作就會餓死的，這個不符合我們數據庫算法調動的方式。

另外就是 CFQ 算法，CFQ 算法不適合我們的數據庫服務器，MySQL 是單操作服務器。所以我們這個算法也不適合我們使用。

一般情況下數據服務器會使用 Deadline 的算法，程序會調用這個時候的 IO 請求去解決這個請求。

這種 Deadline 算法更加適合數據庫，因為這個 Deadline 的算法更加適合。

***一個是文件系統的推薦，我們移動云的數據庫系統就是 Xfs 或者是 Ext4 或者是 Noatime 或者是 nobarrier，這些都會有影響。這是數據庫系統的優化。

數據庫實例的優化

我列了幾個我們在標準化的時候需要規范和配置的參數，這里不一一揭示了。

這些參數很重要，因為它決定了我們實例的性能。某一些參數配置不合理，我們實例的性能就會受到很大的影響。

SQL 語句的優化

這里有編寫高效 SQL 語句的原則，這個原則我們 DBA 要知道，同時要通知業務方的研發，讓他們也知道。

有很多業務側進來都是業務寫的，他沒有經驗的話，就會寫出一些有問題的語句，所以***就變成我們 DBA 要去嚴查。

所以最開始要把這些思想貫徹給業務研發，讓他們按照這個流程去編寫 SQL 的設計。

索引的設計

這里說的是覆蓋索引，比如說有了這個覆蓋索引我們的查詢，查詢的字段都是在這個索引內。

還有我們查詢的后面的字段也是索引，然后還有我們一些排序位置也是覆蓋索引，就是這一系列全部都是中了索引的情況所以就叫覆蓋索引。

這里我也列舉了一些不能使用索引的情況：比如說不要給選擇率低的字段選擇索引，如果通過索引掃描記錄數超過 30% 就變成全表掃描了。

還有 Like 額查詢條件列最左以通配符 % 開始，兩個獨立索引，其中一個用于索引一個用于排序。以上就是對于 MySQL 性能優化的步驟。

自動化運維實踐

所謂自動化運維實踐就相當于是給我們 DBA 提供小工具或者是小幫手，幫助我們打開，而不是糾纏著我們。

我們移動云的體量就是幾百上千臺數據庫的體量，如果我們面對幾臺或者是十幾臺的數據庫的時候，有沒有這個自動化其實無所謂，因為你做自動化反而更加麻煩。

如果你已經有大的量的時候就要平臺化，在自動化的數據庫上進行拓展。以下是我們在自動化運維的實踐經驗。

標準化安裝部署

我們的目錄方案，版本以及部署流程有標準文檔去遵循。比如說一次部署打包多次應用，我們需要在一個節點上把標準包打包起來就一步完成了，那這個標準化的安裝部署就給后面自動化的安裝部署打了一定的基礎。

自動化數據備份

數據備份是我們 DBA 非常重要的一個工作。所以我們公司也是建立合理有效以及規范的自動化備份的規范。

比方說我們的常規備份，我們是每周一次全備，變更前后，有一個業務變更了，在這之前要做一個全備，萬一業務變更哪里出現問題我就可以及時回退。

這個是自動化使用的場景：我們使用的是 innobackup 工具+自動化備份腳本調用+Crontab 定時來做。

自動化日常監控

監控是 DBA 的第三只眼睛，如果建立實時有效的監控非常有效。我們的監控是采用 Zabbix 監控工具。

像確定一些告警閾值這種，一旦超過了這個閾值就可以給我們 DBA 發送短信和郵件，這就是自動化的日常監控。

自動化深度巡檢

這個就是補充了監控所不能達到的地方。比方說如果我們需要掃描或者是看一些大表的情況或者是看一些沒有建索引表的情況，它的輸出很復雜，是一張表或者是幾張表，所以我們就需要深度的巡檢來完成。

深度的巡檢我們公司也是采用開發巡檢腳本，通過 Ansible 統一推送，巡檢報告自動生成。也就是說可以很明確的呈現出這個巡檢的結果供 DBA 去看和去檢查。

自動化故障切換

自動化故障切換是發生在單節點發生故障。比如說變更操作，一些 Keepalive 部署配置，切換腳本，VRRP 協議來實現的。

也是通過編寫一些腳本，那這個腳本可能會定期去檢查我們的數據庫節點的運行狀況。

比如說這個 VIP 有沒有在這個節點或者是進程在不在？一旦發生異常就會自動切換這個節點。

自動化節點擴容

當發生單節點故障的時候，我們需要部署一個新的節點的時候就需要啟動自動化的節點擴容，編寫腳本來做。

自動化安全審計

這就是異常訪問，異常操作可審計追溯。部署安全審計插件，這個安全審計的插件+啟用安全審計日志+日志自動化或者是分析提煉。

所以要不要開啟這個插件根據各位公司對于安全審計方面的要求以及對于性能的要求從兩者取一個平衡。

因為我們還是很看中這個安全事件，所以我們開啟了這個安全審計插件，開啟這個插件以后還需要配置文件做一個配置。

以什么樣的方式存或者是多大？這些參數都可以在配置文件里面進行配置。

自動化密碼審計

這個自動化密碼審計也是一個插件，就是我們安裝了強密碼審查的日志，這個插件的工作原理就是設置了規則，我們需要日志要多少位或者是多少位的大小寫或者是特殊字符的要求。

我們設置密碼的時候必須符合這個強密碼驗證的要求。這個也是進行實時校驗的。

也就是說我們當設一個數據庫用戶的密碼，如果不符合這個強密碼的需求就不會給他通過，防止一些比較容易破解的弱密碼。

自動化日志分析

我們的日志分析挺重要的，如果出現問題就需要這個日志分析，沒有問題正常的時候也需要日志分析工具的。

因為它能夠發生潛在的優化建議，我們采用一個 Percona 為工具 Pt-query-digest，我們只需要看 DBA 的慢日志又可以發現哪些內容存在問題。

自動化數據校驗

我們通過自動化驗校修復工具來做，也是設了 Crontab 的任務讓它定期執行。

自動化數據清理

因為數據庫每天每周都在備份，我們就需要機制定期清理備份文件。

我們也是采用腳本去開發和定時看，如果超過兩個月的備份文件我們就把它刪掉。如果文件都在兩個月就不用管它。超過兩個月就清除它。

自動化日志切分

如果數據庫跑的時間比較長，慢日志或者是錯誤日志比較大，就需要定時檢測日志文件，大于某值則自動切分，否則不處理。

以上就是我們在數據庫運維的沉淀和積累。雖然不像騰訊或者是阿里那么大的體量和經驗，但是以上是我們探索出來的一些經驗，希望可以給各位帶來啟發或者是幫助。