简单粘贴一下我的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
