第一次寫博客，有漏洞的地方希望大佬指正
背景:優化公司老系統中的一條慢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改的。