第一次寫部落格，有漏洞的地方希望大佬指正

背景:優化公司老系統中的一條慢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改的。