記一次簡單的生產環境Mysql調優

第一次寫博客，有漏洞的地方希望大佬指正

背景:優化公司老系統中的一條慢sql,查看執行過程如下:

sql雖然比較簡單，平時執行也沒發現什麼問題，但一到生產環境系統頻繁調用，問題就顯現出來了，整個系統停滯不前，打開Navicat的伺服器監控發現裡面出現好多執行中的sql甚至出現死鎖

查看knowledge_default_operation_log表發現數據10多萬條，knowledge_base_info表1萬多條，由第第一張圖可以明顯的看出knowledge_default_operation_log表沒有走索引，查看該表發現knowledge_base_id欄位上有索引，怎麼回事？

根據以往的經驗又查看knowledge_base_id與knowledge_id的欄位類型，沒問題都是varchar類型啊，往下看發現了問題所在

統一修改排序規則為utf8_general_ci及最終調整sql結構後執行結果如下：

執行時間平均在0.17s左右，線上該模塊慢查詢消失，網上查看資料得知

由於knowledge_default_operation_log表取出的knowledge_base_id欄位是utf8_general_ci字元集，而knowledge_base_info表裡面的knowledge_id是utf8_bin字元集，這裡需要做字元集轉換，字元集轉換遵循由小到大的原則，兩者可能存在字元轉換，轉換了之後，由於knowledge_default_operation_log上面的索引仍然是utf8_general_ci字元集，所以這個索引就被執行計劃忽略了，然後knowledge_default_operation_log表只能選擇全表掃描。knowledge_base_info表如果篩選出來的記錄不止1條，那麼knowledge_default_operation_log就會被全表掃描多次，性能就變慢了。

結章節附註意：生產環境修改字元集不能用alter table xx charset utf8_general_ci，因為生產執行的查詢比較多會引起阻塞，另外也不能修改已經存在欄位值的字元集，我是在業務低峰時期用pt-online-schema-change改的。