面試官：要不你來講講你們對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面試，對線面試官系列持續更新中！
【對線面試官-移動端】系列 一週兩篇持續更新中！
【對線面試官-電腦端】系列 一週兩篇持續更新中！
原創不易！！求三連！！