最近對(duì)數(shù)據(jù)庫做了下梳理和優(yōu)化，使得數(shù)據(jù)庫的成本每月下降20多萬，成本優(yōu)化幅度達(dá)超過80%，這個(gè)數(shù)字一點(diǎn)也不夸張。但是這篇文章不是想炫耀給公司節(jié)約了多少成本，而是想通過一個(gè)具體的案例，給我們技術(shù)人普及一個(gè)最基本理念，那就是如何通過你的專業(yè)度來為公司省錢和提升效率，從而更好的展現(xiàn)我們作為技術(shù)人的價(jià)值。
契機(jī)
最近到了新的部門任職，開展工作的時(shí)候，由于對(duì)數(shù)據(jù)庫相關(guān)的工作非常熟悉，因此切入點(diǎn)就選擇了先從數(shù)據(jù)庫開始，在短短2周的時(shí)間里，讓線上DB的成本下降80%，并且業(yè)務(wù)穩(wěn)定運(yùn)行。這里把我的經(jīng)驗(yàn)整理出來分享給大家，大家如果到了一家新環(huán)境也可以用類似的方法來做數(shù)據(jù)庫相關(guān)的梳理和優(yōu)化工作，在此次的整理中，我從下面幾個(gè)部分來做梳理。
如何梳理
一、數(shù)據(jù)庫實(shí)例梳理
數(shù)據(jù)庫梳理部分，可以詳細(xì)梳理各個(gè)環(huán)境的數(shù)據(jù)庫的資源使用情況，包括數(shù)據(jù)庫的規(guī)格，實(shí)例的數(shù)量等等，一般包含如下幾個(gè)環(huán)境的梳理，有的公司環(huán)境會(huì)有多套，建議分類梳理；
1、DEV環(huán)境數(shù)據(jù)庫梳理
2、QA環(huán)境數(shù)據(jù)庫梳理
3、仿真環(huán)境數(shù)據(jù)庫梳理
4、線上環(huán)境數(shù)據(jù)庫梳理
通過這個(gè)數(shù)據(jù)庫實(shí)例的梳理，你能夠從宏觀上了解線上數(shù)據(jù)庫的部署情況，根據(jù)后面的梳理結(jié)果，可以評(píng)估數(shù)據(jù)使用是否合理以及哪些地方需要做改造和優(yōu)化；
二、DB部署情況梳理
這部分主要是要了解線上數(shù)據(jù)的部署情況，一般包含如下幾個(gè)方面：
1、數(shù)據(jù)庫部署的路徑（程序路徑、數(shù)據(jù)目錄、日志目錄等）
2、數(shù)據(jù)庫使用字符集
3、使用的引擎
4、數(shù)據(jù)庫的版本
5、數(shù)據(jù)庫的核心參數(shù)
? ? ?核心參數(shù)一般包含性能、數(shù)據(jù)一致性等相關(guān)參數(shù)，一般關(guān)注如下幾個(gè)（下面參數(shù)僅僅適用于MySQL數(shù)據(jù)庫）：
?? ?innodb_buffer_pool_size
? ??innodb_flush_log_at_trx_commit
?? ?sync_binlog
?? ?binlog_format
?? ?character_set_server
?? ?character_set_database
?? ?max_connections
? ? 這里僅僅列出了少量比較重要的參數(shù)，大家可以根據(jù)自身的情況做參數(shù)的梳理；
6、實(shí)例高可用
三、DB運(yùn)營情況梳理
這部分涉及的內(nèi)容比較多，大致概括如下：
1、容量使用情況
2、QPS訪問量
3、TPS訪問量
4、慢查詢
5、CPU使用量
6、活動(dòng)線程數(shù)
7、備份方案
8、權(quán)限方案
通過這些信息可以看出一個(gè)實(shí)例的健康度以及實(shí)例資源使用是否合理。
四、DB相關(guān)需求調(diào)研
調(diào)研相關(guān)的需求，比如對(duì)高可用的需求、對(duì)數(shù)據(jù)一致性的需求、分庫分表、數(shù)據(jù)回滾等需求，通過這些需求能知道現(xiàn)在線上的部署模式是否符合要求。
舉個(gè)簡單的列子：
比如業(yè)務(wù)有數(shù)據(jù)強(qiáng)一致性的需求，而線上同步方式是異步，以及innodb_flush_log_at_trx_commit和sync_binlog參數(shù)并不是雙1，那么這里就存在風(fēng)險(xiǎn)，需要做相應(yīng)的改造。
思考和分析
在完成資料的收集以后，下一步就是根據(jù)自己的專業(yè)度進(jìn)行分析和思考，下面列舉幾個(gè)思考的維度，大家在工作中可以經(jīng)常這么去反問自己，然后思考出答案。
1、資源使用合理嗎？
? ? 一般根據(jù)存儲(chǔ)容量、QPS、TPS以及CPU的使用情況就可以很清楚的確認(rèn)實(shí)例的運(yùn)行狀態(tài)，是過于空閑、負(fù)載適中還是高負(fù)載？然后根據(jù)具體的情況對(duì)數(shù)據(jù)庫做實(shí)例縮容或者擴(kuò)容。
2、數(shù)據(jù)庫參數(shù)設(shè)置合理嗎？
3、實(shí)例負(fù)載是否在正常范圍？
4、實(shí)例的權(quán)限是否設(shè)置合理？
? ? 權(quán)限這部分比較好評(píng)估，是否存在業(yè)務(wù)權(quán)限過大的情況？root的權(quán)限是否有限定訪問IP？這里一般的原則是：
業(yè)務(wù)權(quán)限一般只給select/insert/update三個(gè)權(quán)限就OK
禁止針對(duì)賬號(hào)做%的授權(quán)
root用戶只由DBA控制
5、是否存在低版本，以及低版本是否需要升級(jí)？
? ? 線上一般需要保持版本的統(tǒng)一，特殊情況除外。
6、數(shù)據(jù)一致性需求能滿足嗎？
7、實(shí)例是否需要高可用？
8、慢查詢是否正常？
9、索引設(shè)計(jì)是否合理？
? ? 索引這里一般根據(jù)慢查詢來判斷，還有一個(gè)維度，大家可以通過pt的pt-duplicate-key-checker工具來看線上是否存在重復(fù)的索引，比如如下的索引：
10、數(shù)據(jù)庫的變更流程是否合理？
11、實(shí)例監(jiān)控是否合理？
12、實(shí)例的備份策略是否合理？
上面列出了我自己常用的一些主要的維度，大家可以根據(jù)自身的情況酌情添加或者刪除。
改造
根據(jù)上面的分析，就可以進(jìn)一步對(duì)DB做優(yōu)化，這里需要根據(jù)具體的情況來進(jìn)行推進(jìn)，就我們現(xiàn)在的DB存在的問題，我做了如下的優(yōu)化：
1、實(shí)例降級(jí)和升級(jí)改造
? ? 僅僅這一步就為公司每個(gè)月節(jié)約成本20多萬。
? ? 注意：實(shí)例降級(jí)需要準(zhǔn)確評(píng)估實(shí)例的負(fù)載情況，并對(duì)線上留有比較大的余量的情況下進(jìn)行，把控好風(fēng)險(xiǎn)。
2、版本升級(jí)
3、監(jiān)控告警優(yōu)化
4、權(quán)限改造
5、SQL和索引優(yōu)化
6、變更流程規(guī)范化
總結(jié)
做了前面的工作，你可以把前面你做得事情整理成一封非常好的郵件，你的優(yōu)化成果、思考以及項(xiàng)目推進(jìn)的詳細(xì)過程，還有別忘記記錄其中遇到的問題和經(jīng)驗(yàn)教訓(xùn)。
總結(jié)的時(shí)候可以用思維導(dǎo)圖來展現(xiàn)，比如下面的圖：
備注：記住，這一步非常重要，公司中不僅要積極主動(dòng)干事情，也要積極主動(dòng)的總結(jié)和回報(bào)，曾經(jīng)自己因?yàn)橹恢缆耦^干事情吃了不少虧，大家一定要謹(jǐn)記。
