面試官：要不你來講講你們對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面試，對線面試官系列持續更新中！
【對線面試官-移動端】系列 一周兩篇持續更新中！
【對線面試官-電腦端】系列 一周兩篇持續更新中！
原創不易！！求三連！！
更多的文章可往：文章的目錄導航轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/310353.html
標籤：其他
上一篇：純凈Ubuntu16安裝CUDA(9.1)和cuDNN
下一篇：全套Java教程_Java基礎入門教程，零基礎小白自學Java必備教程 🐱# 013 # 第十三單元 繼承、super、this、抽象類 #