資料庫優化的幾個階段

大家在面試的時候，是否遭遇過，面試官詢問

你們是如何進行資料庫優化的?

這才是調優的第一階段啊，為什麼呢？因為這一步成本最低啊，不需要加什麼中介軟體。你沒經過索引優化和sql優化，就來什麼水平拆分，這不是坑人麼。

那步驟是什麼樣呢?我說個大概

(1)用慢查詢日誌定位執行效率低的sql語句

(2)用explain分析sql的執行計畫

(3)確定問題，採取相應的優化措施，建立索引啊，等

我就不舉例了，因為如何優化sql的文章，一抓一大把，再貼過來，讀者看著也累。

在優化sql無法解決問題的情況下，才考慮搭建快取。畢竟你使用快取的目的，就是將複雜的、耗時的、不常變的執行結果快取起來，降低資料庫的資源消耗。

這裡需要注意的是:搭建快取後，系統的複雜性增加了。你需要考慮很多問題，比如:

快取也搞不定的情況下，搞主從複製，上讀寫分離。在應用層，區分讀寫請求。或者利用現成的中介軟體mycat或者altas等做讀寫分離。

需要注意的是,只要你敢說你用了主從架構，有三個問題，你要準備:

(1)主從的好處？

回答:實現資料庫備份，實現資料庫負載均衡，提高資料庫可用性

(2)主從的原理?

回答:如圖所示（不是自己畫的，偷懶了）

主庫有乙個log dump執行緒，將binlog傳給從庫

從庫有兩個執行緒，乙個i/o執行緒，乙個sql執行緒，i/o執行緒讀取主庫傳過來的binlog內容並寫入到relay log,sql執行緒從relay log裡面讀取內容，寫入從庫的資料庫。

(3)如何解決主從一致性?

回答:這個問題，我不建議在資料庫層面解決該問題。根據cap定理，主從架構本來就是一種高可用架構，是無法滿足一致性的。

哪怕你採用同步複製模式或者半同步複製模式，都是弱一致性，並不是強一致性。所以，推薦還是利用快取，來解決該問題。

步驟如下:

1、自己通過測試，計算主從延遲時間，建議mysql版本為5.7以後，因為mysql自5.7開始，多執行緒複製功能比較完善，一般能保證延遲在1s內。不過話說回來，mysql現在都出到8.x了，還有人用5.x的版本麼。

2、資料庫的寫操作，先寫資料庫，再寫cache，但是有效期很短，就比主從延時的時間稍微長一點。

3、讀請求的時候，先讀快取，快取存在則直接返回。如果快取不存在(這時主從同步已經完成)，再讀資料庫。

說句實在話，你們面試的時候，其實可以略過這個階段。因為很多網際網路公司都不建議用分割槽表，我自己也不太建議用分割槽表，採用這個分割槽表，坑太多。

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

什麼是mysql的分割槽表？

回答：所有資料還在乙個表中，但物理儲存根據一定的規則放在不同的檔案中。這個是mysql支援的功能，業務**不需要改動，但是sql語句需要改動，sql條件需要帶上分割槽的列。

缺點

(1)分割槽鍵設計不太靈活，如果不走分割槽鍵，很容易出現全表鎖

(2)在分割槽表使用alter table…order by，只能在每個分區內進行order by。

(3)分割槽表的分割槽鍵建立索引，那麼這個索引也將被分割槽。分割槽鍵沒有全域性索引一說。

(4)自己分庫分表，自己掌控業務場景與訪問模式，可控。分割槽表，研發寫了乙個sql，都不確定該去哪個分割槽查，不太可控。

…不列舉了，不推薦

ok,水平拆分是最麻煩的乙個階段，拆分後會有很多的問題，我再強調一次，水平拆分一定是最最最最後的選擇。從某種意義上，我覺得還不如垂直拆分。因為你用垂直拆分，分成不同模組後，發現單模組的壓力過大，你完全可以給該模組單獨做優化，例如提高該模組的機器配置等。如果是水平拆分，拆成兩張表，**需要變動，然後發現兩張表還不行，再變**，再拆成三張表的？水平拆分後，各模組間耦合性太強，成本太大，慎重。

資料庫優化的幾個階段

資料庫優化的幾個階段

資料庫優化的幾個階段

優化mysql資料庫的幾個步驟

相關推薦