面試官問我MySQL調優，我真的是

• 2021 年 10 月 12 日
• 筆記

面試官：要不你來講講你們對MySQL是怎麼調優的？

候選者：哇，這命題很大阿…我認為，對於開發者而言，對MySQL的調優重點一般是在「開發規範」、「資料庫索引」又或者說解決線上慢查詢上。

候選者：而對於MySQL內部的參數調優，由專業的DBA來搞。

面試官：扯了這麼多，你就是想表達你不會MySQL參數調優，對吧

候選者：草，被發現了。

面試官：那你來聊聊你們平時開發的規範和索引這塊，平時是怎麼樣的吧。

候選者：嗯，首先，我們在生產環境下，創建資料庫表，都是在工單系統下完成的（那就自然需要DBA審批）。如果在創建表時檢測到沒有創建索引，那就會直接提示warning（：

候選者：理論上來說，如果表有一定的數據量，那就應該要創建對應的索引。從資料庫查詢數據需要注意的地方還是蠻多的，其中很多都是平時積累來的。比如說：

候選者：1. 是否能使用「覆蓋索引」，減少「回表」所消耗的時間。意味著，我們在select 的時候，一定要指明對應的列，而不是select *

候選者：2. 考慮是否組建「聯合索引」，如果組建「聯合索引」，盡量將區分度最高的放在最左邊，並且需要考慮「最左匹配原則」

候選者：3.對索引進行函數操作或者表達式計算會導致索引失效

候選者：4.利用子查詢優化超多分頁場景。比如 limit offset , n 在MySQL是獲取 offset + n的記錄，再返回n條。而利用子查詢則是查出n條，通過ID檢索對應的記錄出來，提高查詢效率。

面試官：嗯…

候選者：5.通過explain命令來查看SQL的執行計劃，看看自己寫的SQL是否走了索引，走了什麼索引。通過show profile 來查看SQL對系統資源的損耗情況（不過一般還是比較少用到的）

候選者：6.在開啟事務後，在事務內儘可能只操作資料庫，並有意識地減少鎖的持有時間（比如在事務內需要插入&&修改數據，那可以先插入後修改。因為修改是更新操作，會加行鎖。如果先更新，那並發下可能會導致多個事務的請求等待行鎖釋放）

面試官：嗯，你提到了事務，之前也講過了事務的隔離級別嘛，那你線上用的是什麼隔離級別？

候選者：嗯，我們這邊用的是Read Commit（讀已提交），MySQL默認用的是Repeatable read（可重複讀）。選用什麼隔離級別，主要看應用場景嘛，因為隔離級別越低，事務並發性能越高。

候選者：（一般互聯網公司都選擇Read Commit作為主要的隔離級別）

候選者：像Repeatable read（可重複讀）隔離級別，就有可能因為「間隙鎖」導致的死鎖問題。

候選者：但可能你已經知道，MySQL默認的隔離級別為Repeatable read。很大一部分原因是在最開始的時候，MySQL的binlog沒有row模式，在read commit隔離級別下會存在「主從數據不一致」的問題

候選者：binlog記錄了資料庫表結構和表數據「變更」，比如update/delete/insert/truncate/create。在MySQL中，主從同步實際上就是應用了binlog來實現的（：

候選者：有了該歷史原因，所以MySQL就將默認的隔離級別設置為Repeatable read

面試官：嗯，那我順便想問下，你們遇到過類似的問題嗎：即便走對了索引，線上查詢還是慢。

候選者：嗯嗯，當然遇到過了

面試官：那你們是怎麼做的？

候選者：如果走對了索引，但查詢還是慢，那一般來說就是表的數據量實在是太大了。

候選者：首先，考慮能不能把「舊的數據」給”刪掉”，對於我們公司而言，我們都會把數據同步到Hive，說明已經離線存儲了一份了。

候選者：那如果「舊的數據」已經沒有查詢的業務了，那最簡單的辦法肯定是”刪掉”部分數據咯。數據量降低了，那自然，檢索速度就快了…

面試官：嗯，但一般不會刪的

候選者：沒錯，只有極少部分業務可以刪掉數據（：

候選者：隨後，就考慮另一種情況，能不能在查詢之前，直接走一層快取（Redis）。

候選者：而走快取的話，又要看業務能不能忍受讀取的「非真正實時」的數據（畢竟Redis和MySQL的數據一致性需要保證），如果查詢條件相對複雜且多變的話（涉及各種group by 和sum），那走快取也不是一種好的辦法，維護起來就不方便了…

候選者：再看看是不是有「字元串」檢索的場景導致查詢低效，如果是的話，可以考慮把表的數據導入至Elasticsearch類的搜索引擎，後續的線上查詢就直接走Elasticsearch了。

候選者：MySQL->Elasticsearch需要有對應的同步程式(一般就是監聽MySQL的binlog，解析binlog後導入到Elasticsearch)

候選者：如果還不是的話，那考慮要不要根據查詢條件的維度，做相對應的聚合表，線上的請求就查詢聚合表的數據，不走原表。

候選者：比如，用戶下單後，有一份訂單明細，而訂單明細表的量級太大。但在產品側(前台)透出的查詢功能是以「天」維度來展示的，那就可以將每個用戶的每天數據聚合起來，在聚合表就是一個用戶一天只有一條匯總後的數據。

候選者：查詢走聚合後的表，那速度肯定杠杠的（聚合後的表數據量肯定比原始表要少很多）

候選者：思路大致的就是「以空間換時間」，相同的數據換別的地方也存儲一份，提高查詢效率

面試官：那我還想問下，除了讀之外，寫性能同樣有瓶頸，怎麼辦？

候選者：你說到這個，我就不困了。

候選者：如果在MySQL讀寫都有瓶頸，那首先看下目前MySQL的架構是怎麼樣的。

候選者：如果是單庫的，那是不是可以考慮升級至主從架構，實現讀寫分離。

候選者：簡單理解就是：主庫接收寫請求，從庫接收讀請求。從庫的數據由主庫發送的binlog進而更新，實現主從數據一致（在一般場景下，主從的數據是通過非同步來保證最終一致性的）

面試官：嗯…

候選者：如果在主從架構下，讀寫仍存在瓶頸，那就要考慮是否要分庫分表了

候選者：至少在我前公司的架構下，業務是區分的。流量有流量資料庫，廣告有廣告的資料庫，商品有商品的資料庫。所以，我這裡講的分庫分表的含義是：在原來的某個庫的某個表進而拆分。

候選者：比如，現在我有一張業務訂單表，這張訂單表在廣告庫中，假定這張業務訂單表已經有1億數據量了，現在我要分庫分表

候選者：那就會將這張表的數據分至多個廣告庫以及多張表中（：

候選者：分庫分表的最明顯的好處就是把請求進行均攤（本來單個庫單個表有一億的數據，那假設我分開8個庫，那每個庫1200+W的數據量，每個庫下分8張表，那每張表就150W的數據量）。

面試官：你們是以什麼來作為分庫鍵的？

候選者：按照我們這邊的經驗，一般來說是按照userId的（因為按照用戶的維度查詢比較多），如果要按照其他的維度進行查詢，那還是參照上面的的思路（以空間換時間）。

面試官：那分庫分表後的ID是怎麼生成的？

候選者：這就涉及到分散式ID生成的方式了，思路有很多。有藉助MySQL自增的，有藉助Redis自增的，有基於「雪花演算法」自增的。具體使用哪種方式，那就看公司的技術棧了，一般使用Redis和基於「雪花演算法」實現用得比較多。

候選者：至於為什麼強調自增（還是跟索引是有序有關，前面已經講過了，你應該還記得）

面試官：嗯，那如果我要分庫分表了，遷移的過程是怎麼樣的呢

候選者：我們一般採取「雙寫」的方式來進行遷移，大致步驟就是：

候選者：一、增量的消息各自往新表和舊錶寫一份

候選者：二、將舊錶的數據遷移至新庫

候選者：三、遲早新表的數據都會追得上舊錶（在某個節點上數據是同步的）

候選者：四、校驗新表和老表的數據是否正常（主要看能不能對得上）

候選者：五、開啟雙讀（一部分流量走新表，一部分流量走老表），相當於灰度上線的過程

候選者：六、讀流量全部切新表，停止老表的寫入

候選者：七、提前準備回滾機制，臨時切換失敗能恢復正常業務以及有修數據的相關程式。

面試官：嗯…今天就到這吧

本文總結：

• 資料庫表存在一定數據量，就需要有對應的索引
• 發現慢查詢時，檢查是否走對索引，是否能用更好的索引進行優化查詢速度，查看使用索引的姿勢有沒有問題
• 當索引解決不了慢查詢時，一般由於業務表的數據量太大導致，利用空間換時間的思想
• 當讀寫性能均遇到瓶頸時，先考慮能否升級資料庫架構即可解決問題，若不能則需要考慮分庫分表
• 分庫分表雖然能解決掉讀寫瓶頸，但同時會帶來各種問題，需要提前調研解決方案和踩坑

線上不是給你炫技的地方，安穩才是硬道理。能用簡單的方式去解決，不要用複雜的方式

歡迎關注我的微信公眾號【Java3y】來聊聊Java面試，對線面試官系列持續更新中！

【對線面試官-移動端】系列 一周兩篇持續更新中！

【對線面試官-電腦端】系列 一周兩篇持續更新中！

原創不易！！求三連！！