大家在面試的時(shí)候經(jīng)常會(huì)被問到數(shù)據(jù)庫(kù)優(yōu)化的問題，今天給大家總結(jié)了幾點(diǎn)：

第一階段 優(yōu)化sql和索引

這才是調(diào)優(yōu)的第一階段啊，為什么呢？

因?yàn)檫@一步成本最低啊，不需要加什么中間件。

那步驟是什么樣呢?我說個(gè)大概

用慢查詢?nèi)罩径ㄎ粓?zhí)行效率低的SQL語句

用explain分析SQL的執(zhí)行計(jì)劃

確定問題，采取相應(yīng)的優(yōu)化措施，建立索引等

第二階段 使用緩存

在優(yōu)化sql無法解決問題的情況下，才考慮搭建緩存。畢竟你使用緩存的目的，就是將復(fù)雜的、耗時(shí)的、不常變的執(zhí)行結(jié)果緩存起來，降低數(shù)據(jù)庫(kù)的資源消耗。

這里需要注意的是:搭建緩存后，系統(tǒng)的復(fù)雜性增加了。你需要考慮很多問題，比如:

緩存和數(shù)據(jù)庫(kù)一致性問題？(比如是更緩存，還是刪緩存)

緩存擊穿、緩存穿透、緩存雪崩問題如何解決？是否有做緩存預(yù)熱的必要。不過我猜，大部分中小公司應(yīng)該都沒考慮。

第三階段 讀寫分離

緩存也搞不定的情況下，搞主從復(fù)制，上讀寫分離。在應(yīng)用層，區(qū)分讀寫請(qǐng)求?；蛘呃矛F(xiàn)成的中間件mycat或者altas等做讀寫分離。

需要注意的是,只要你敢說你用了主從架構(gòu)，有三個(gè)問題，你要準(zhǔn)備:

1.主從的好處？

回答:實(shí)現(xiàn)數(shù)據(jù)庫(kù)備份，實(shí)現(xiàn)數(shù)據(jù)庫(kù)負(fù)載均衡，提高數(shù)據(jù)庫(kù)可用性

2.主從的原理?

回答:如圖所示

主庫(kù)有一個(gè)log dump線程，將binlog傳給從庫(kù)

從庫(kù)有兩個(gè)線程，一個(gè)I/O線程，一個(gè)SQL線程，I/O線程讀取主庫(kù)傳過來的binlog內(nèi)容并寫入到relay log,SQL線程從relay log里面讀取內(nèi)容，寫入從庫(kù)的數(shù)據(jù)庫(kù)。

3.如何解決主從一致性?

回答:這個(gè)問題，我不建議在數(shù)據(jù)庫(kù)層面解決該問題。根據(jù) CAP 定理，主從架構(gòu)本來就是一種高可用架構(gòu)，是無法滿足一致性的。

哪怕你采用同步復(fù)制模式或者半同步復(fù)制模式，都是弱一致性，并不是強(qiáng)一致性。所以，推薦還是利用緩存，來解決該問題。

步驟如下:

自己通過測(cè)試，計(jì)算主從延遲時(shí)間，建議mysql版本為5.7以后，因?yàn)閙ysql自5.7開始，多線程復(fù)制功能比較完善，一般能保證延遲在1s內(nèi)。不過話說回來，mysql現(xiàn)在都出到8.x了，還有人用5.x的版本么。

數(shù)據(jù)庫(kù)的寫操作，先寫數(shù)據(jù)庫(kù)，再寫cache，但是有效期很短，就比主從延時(shí)的時(shí)間稍微長(zhǎng)一點(diǎn)。

讀請(qǐng)求的時(shí)候，先讀緩存，緩存存在則直接返回。如果緩存不存在(這時(shí)主從同步已經(jīng)完成)，再讀數(shù)據(jù)庫(kù)。

第四階段 利用分區(qū)表

說句實(shí)在話，你們面試的時(shí)候，其實(shí)可以略過這個(gè)階段。因?yàn)楹芏嗷ヂ?lián)網(wǎng)公司都不建議用分區(qū)表，我自己也不太建議用分區(qū)表，采用這個(gè)分區(qū)表，坑太多。

這里引用一下其他文章的回答:

什么是mysql的分區(qū)表？

回答：所有數(shù)據(jù)還在一個(gè)表中，但物理存儲(chǔ)根據(jù)一定的規(guī)則放在不同的文件中。這個(gè)是mysql支持的功能，業(yè)務(wù)代碼不需要改動(dòng)，但是sql語句需要改動(dòng)，sql條件需要帶上分區(qū)的列。

缺點(diǎn)

分區(qū)鍵設(shè)計(jì)不太靈活，如果不走分區(qū)鍵，很容易出現(xiàn)全表鎖

在分區(qū)表使用ALTER TABLE … ORDER BY，只能在每個(gè)分區(qū)內(nèi)進(jìn)行order by。

分區(qū)表的分區(qū)鍵創(chuàng)建索引，那么這個(gè)索引也將被分區(qū)。分區(qū)鍵沒有全局索引一說。

自己分庫(kù)分表，自己掌控業(yè)務(wù)場(chǎng)景與訪問模式，可控。分區(qū)表，研發(fā)寫了一個(gè)sql，都不確定該去哪個(gè)分區(qū)查，不太可控。

第五階段 垂直拆分

上面四個(gè)階段都沒搞定，就來垂直拆分了。垂直拆分的復(fù)雜度還是比水平拆分小的。將你的表，按模塊拆分為不同的小表。大家應(yīng)該都看過《大型網(wǎng)站架構(gòu)演變之路》，這種類型的文章或者書籍，基本都有提到這一階段。

如果你有幸能夠在什么運(yùn)營(yíng)商、銀行等公司上班，你會(huì)發(fā)現(xiàn)他們一個(gè)表，幾百個(gè)字段都是很常見的事情。所以，應(yīng)該要進(jìn)行拆分，拆分原則一般是如下三點(diǎn):

把不常用的字段單獨(dú)放在一張表。

把常用的字段單獨(dú)放一張表

經(jīng)常組合查詢的列放在一張表中（聯(lián)合索引）。

第六階段 水平拆分

水平拆分是最麻煩的一個(gè)階段，拆分后會(huì)有很多的問題，我再?gòu)?qiáng)調(diào)一次，水平拆分一定是最最最最后的選擇。從某種意義上，我覺得還不如垂直拆分。因?yàn)槟阌么怪辈鸱郑殖刹煌K后，發(fā)現(xiàn)單模塊的壓力過大，你完全可以給該模塊單獨(dú)做優(yōu)化，例如提高該模塊的機(jī)器配置等。如果是水平拆分，拆成兩張表，代碼需要變動(dòng)，然后發(fā)現(xiàn)兩張表還不行，再變代碼，再拆成三張表的？水平拆分后，各模塊間耦合性太強(qiáng)，成本太大，慎重。