簡單粘貼一下我的sql：
同事告訴我，界面打開很慢，總共訂單數據只有100多條，理論上不應該這麼慢的，然後找到對應的sql語句，進行簡單的分析，
背景交代一下：mysql5.7，工具Navicat12 ，本人對mysql也就是屬於可以用的層級
分析的步驟：
1.先對sql做精簡，測試幾次過後發現 left join mdm_consignee 對效率影響特別大，註釋之前需要查詢 0.7秒多點，註釋之後只需要查詢0.02秒，問題已定位。
2.查找mdm_consignee表中是否有索引，確實沒有，然後添加索引（PS:個人覺得和索引關係不大，原因是表中的數據量太小，不足以到使用索引的量級），再次查詢依然無效。
3.多出查詢資料，關於left join較慢的資料都查詢過，但是都並不符合我這種情況，所以作罷，開始實打實的分析sql執行計劃。
4.在sql語句前面添加 EXPLAIN 關鍵字，然後執行查詢，發現我的left join mdm_consignee表(總行數有5000多條)沒有走索引，搜索資料過後發現一篇文章，大意是你的left join不走索引的原因是 兩個字段的字符集不同，然後我檢查了一下我本地兩個表對應連接字段的字符集排序規則，SHOW FULL COLUMNS FROM mdm_consignee(展示表所有列相關信息); 發現兩個列確實字符集排序不一致，原因估計就是不同同事之間本地建數據庫時沒有統一規範，後續提醒所有同事進行注意。
5.調整字段的排序規則，語句如下：
ALTER TABLE tm_order CHANGE FROM_CONSIGNEE_ID FROM_CONSIGNEE_ID VARCHAR(64) CHARACTER SET utf8 COLLATE utf8_general_ci;
更改過後重試語句，查詢耗時只需要0.0幾秒；刪除索引再試，效果相同，也只需要耗時0.0幾秒，與索引無關。
爲了防止其他地方出現相同問題：輸出一個更改所有表的字符集腳本
SELECT CONCAT('ALTER TABLE ', table_name, ' CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;')
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'alotwms3' ；
————————————————
版權聲明：本文爲CSDN博主「god_is_gril」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/god_is_gril/article/details/85855755