通常使用CPU利用率衡量CPU的繁忙程度，通過top命令，開發(fā)者可以查看CPU利用率實時變化。CPU 利用率持續(xù)超過80%，預示計算資源已經(jīng)接近飽和，如果開發(fā)者已經(jīng)做過SQL優(yōu)化，則需要使用更高配置的CPU。通過查看7天內(nèi)CPU利用率超過80%的時間占整體時間的百分比，以及單次持續(xù)時間超過一定閾值，則可視為CPU擴容的觸發(fā)條件。

大部分數(shù)據(jù)庫應用都是的IO Bound類型，IO 處理能力直接決定了數(shù)據(jù)庫的性能。IO 利用率統(tǒng)計了一秒內(nèi)IO請求隊列非空的時間比例，IO利用率越高就表示硬盤越繁忙。

存儲空間

存儲空間不足會導致嚴重的系統(tǒng)故障，數(shù)據(jù)庫可能會宕機，更為嚴重的是數(shù)據(jù)庫進程存活，但是無法響應服務，從而造成基于進程的宕機監(jiān)控失效。

內(nèi)存

使用InnoDB存儲引擎的MySQL數(shù)據(jù)庫在實例啟動時，就會預分配一塊固定大小的內(nèi)存空間，所有讀寫請求都會在該空間中完成，如果內(nèi)存中緩存了用戶讀寫的數(shù)據(jù)，則直接讀取內(nèi)存，如果內(nèi)存中沒有用戶讀寫的數(shù)據(jù)，則需要將數(shù)據(jù)先從硬盤中load進內(nèi)存中，由于內(nèi)存的讀寫速度遠遠快于硬盤，這就使得讀寫請求是否命中內(nèi)存決定了讀寫請求的處理速度。內(nèi)存空間越大，緩存數(shù)據(jù)越多，命中的幾率也就越大。

網(wǎng)絡

網(wǎng)絡帶寬在數(shù)據(jù)庫返回記錄較多的情況下，也可能會成為系統(tǒng)的瓶頸。一般我們使用每秒網(wǎng)絡流入和流出字節(jié)數(shù)來衡量網(wǎng)絡流量是否達到帶寬限制。

三、服務安全

弱口令

MySQL的登陸認證使用的是IP和賬戶密碼的方式，很多開發(fā)者為了方便記憶，習慣將數(shù)據(jù)庫密碼設置為弱密碼，這實際是非常危險的。數(shù)據(jù)庫中的數(shù)據(jù)很多涉及敏感業(yè)務，弱密碼非常容易被破解，對數(shù)據(jù)庫中的數(shù)據(jù)是一個嚴重安全隱患。MySQL系統(tǒng)庫mysql庫下的user表的password字段保存了所有用戶的密碼，MySQL使用的是兩次sha-1的不可逆加密算法，所以我們無法通過password字段獲取用戶的密碼內(nèi)容，但是我們可以通過將常見弱密碼制成彩虹表，模擬MySQL的加密算法，匹配password字段，即可發(fā)現(xiàn)數(shù)據(jù)庫中的弱密碼賬號。

網(wǎng)絡安全

在一般的業(yè)務架構(gòu)中，數(shù)據(jù)庫都不會直接服務于終端用戶，而是服務于運行業(yè)務邏輯的應用程序。所以數(shù)據(jù)庫和業(yè)務程序之間出于安全的考慮，會選擇使用私有網(wǎng)絡。即便如此，為了避免數(shù)據(jù)庫連錯，也需要在設置數(shù)據(jù)庫賬號時，增加IP來源限制。在一些特定的場景下，如果數(shù)據(jù)訪問必須借助公網(wǎng)來實現(xiàn)，就會將數(shù)據(jù)庫暴漏在公網(wǎng)上。使用公網(wǎng)數(shù)據(jù)庫實例，必須要配置防火墻，否則存在被攻擊的隱患。通過iptables我們可以控制訪問數(shù)據(jù)庫的來源IP。

權(quán)限檢查

MySQL提供了多種權(quán)限配置，為了方便管理以及避免誤操作，一般會將管理權(quán)限和訪問權(quán)限配置成兩個不同的賬號，禁止使用管理權(quán)限作為業(yè)務程序訪問數(shù)據(jù)庫的賬號。通過系統(tǒng)庫mysql庫的user表可以確認各個賬號擁有的權(quán)限，盡量避免業(yè)務賬號擁有super權(quán)限。

四、參數(shù)配置

內(nèi)存相關(guān)參數(shù)

MySQL數(shù)據(jù)庫的內(nèi)存使用包括兩個部分：共享內(nèi)存與連接獨占內(nèi)存。每一個用戶新建連接，數(shù)據(jù)庫都要分配一塊固定大小的內(nèi)存空間保存用戶的臨時數(shù)據(jù)，這些空間為單個連接獨占。在MySQL實例啟動時，系統(tǒng)同時也會預先分配一些實例級別的共享內(nèi)存空間，例如Innodb_buffer_pool，Innodb_log_buffer_pool等，供所有連接共享。獨占內(nèi)存空間乘以最大連接數(shù)加上共享內(nèi)存空間，我們可以計算出MySQL最大可使用的內(nèi)存空間，如果超過實際物理內(nèi)存大小，就存在MySQL進程被Linux操作系統(tǒng)強行oom kill風險，導致實例宕機。MySQL的這些內(nèi)存空間都可以通過配置參數(shù)指定大小，如果超過實際內(nèi)存空間，應該調(diào)整相應參數(shù)配置，最常見的是調(diào)整Innodb_buffer_pool和最大連接數(shù)。

頻繁卡頓

如果設置過大，會導致數(shù)據(jù)庫實例重啟或者故障恢復花費大量的時間。一般，對于使用固態(tài)硬盤等高配置的存儲設備的數(shù)據(jù)庫，可以將重做日志設置大一些，對于使用機械硬盤的數(shù)據(jù)庫，應該設置小一些，一般在512M到4G之間。innodb_flush_log_at_trx_commit定義了重做日志的刷新節(jié)奏，如果該參數(shù)非1，會導致數(shù)據(jù)庫宕機重啟后丟失部分更新數(shù)據(jù)，對于數(shù)據(jù)可靠性要求較高的應用造成嚴重影響。

二進制日志相關(guān)參數(shù)

binlog 主要用于MySQL集群復制以及故障恢復擔任協(xié)調(diào)者的作用。binlog_format定義了binlog的格式，主要包括ROW、STATEMENT、MIXED三種格式，ROW格式是最安全的一種日志格式，會保證主從數(shù)據(jù)的嚴格一致，建議開發(fā)者選用ROW格式。但是ROW格式的binlog會占用更多的存儲空間，通過expire_logs_days可以控制保存binlog的天數(shù)，如果binlog占用的存儲空間比例超過50%，則應考慮適當減少binlog的保存天數(shù)。sync_binlog 參數(shù)定義了binlog刷新硬盤的節(jié)奏，如果非1，會導致宕機重啟后最近的更新數(shù)據(jù)丟失。

連接數(shù)相關(guān)參數(shù)

MySQL有最大連接數(shù)限制max_connections，如果應用連接超過max_connetions限制，則會得到out of max connections異常，無法建立連接。showprocesslist可以查看當前的連接數(shù)，如果接近最大限制，則存在無法新建連接的風險。通過在應用端使用連接池可以控制數(shù)據(jù)庫的連接數(shù)。

五、用戶訪問

慢連接

慢查詢數(shù)量是最直觀的反映數(shù)據(jù)庫處理能力是否滿足業(yè)務需求的指標。通過設置slow_query_log可以開啟慢查詢?nèi)罩荆?/span>MySQL數(shù)據(jù)庫會將執(zhí)行時間超過long_query_time的查詢記入慢查詢?nèi)罩荆绻硞€時間段內(nèi)，慢查詢數(shù)量急劇增加，則開發(fā)者就必須要關(guān)注數(shù)據(jù)庫的性能問題，首先就需要進行SQL優(yōu)化，其次考慮資源是否需要擴容，最后可能需要數(shù)據(jù)庫水平擴展方案，包括創(chuàng)建只讀從節(jié)點。

死鎖數(shù)量

兩個事務涉及的數(shù)據(jù)庫記錄有重疊，如果SQL語句的加鎖順序不一致，就會導致事務之間的死鎖。雖然MySQL數(shù)據(jù)庫會自動的檢測死鎖并強制回滾系統(tǒng)認為代價較小的事務，但是死鎖的檢測與事務回滾都有較大的代價，會嚴重拖慢數(shù)據(jù)庫的性能，所以當系統(tǒng)中出現(xiàn)大量死鎖時，開發(fā)者必須引起重視，要分析發(fā)生死鎖的事務的SQL語句的加鎖規(guī)則，調(diào)整SQL語句。通過show engin innodb status可以查看死鎖的相關(guān)信息以及系統(tǒng)的處理過程。

集群復制

數(shù)據(jù)安全

復制是MySQL多個節(jié)點之間實現(xiàn)數(shù)據(jù)同步的重要機制，主要用于搭建高可用實例主從節(jié)點以及提供多個只讀從節(jié)點提高讀擴展能力。節(jié)點之間的數(shù)據(jù)是否最終一致對于高可用方案是否生效，只讀實例讀取的數(shù)據(jù)是否正確有著嚴重影響。從機執(zhí)行show slave status可以獲取從機的復制狀態(tài)，Slave_IO_Running和Slave_SQL_Running分別表示IO和SQL線程是否正常運行，如果不正常，則應及時處理。參數(shù)relay_log_recovery和relay_log_info_repository影響從節(jié)點宕機重啟后，與主機的復制位置是否正確，如果位置錯誤，則可能導致數(shù)據(jù)錯誤。

復制性能

復制延遲經(jīng)常用來評估復制性能是否滿足業(yè)務需求。Show slave status的Seconds behind master字段標識了從機落后主機的延遲時間。如果延遲較長，則會影響高可用實例主從切換的時間以及只讀從節(jié)點是否能夠及時讀到最新數(shù)據(jù)。通過使用并行復制技術(shù)可以提高從節(jié)點的復制性能。MySQL 5.6提供了基于Database級別的并行復制，通過slave_parallel_workers 設置并行線程數(shù)；MySQL 5.7提供了基于LOGICAL_CLOCK的并行復制，主機上同一個Group提交的binlog中包含事務在從機并行執(zhí)行，相比database，具備更高的并發(fā)性，除了設置slave_parallel_workers，還需要將slave-parallel-type設置為LOGICAL_CLOCK。slave_preserve_commit_order=1可以確保從機并行執(zhí)行的事務按序提交。同時從機的log_bin和log_slave_updates參數(shù)必須同時開啟。