今天，咱就来聊聊一个让人意想不到却又经常出现的SQL优化“陷阱”——因字符集不同导致的索引失效问题。这问题看似不起眼，却能让查询效率大幅下降，坑苦不少开发小伙伴。

一、离奇的查询卡顿

前段时间，我遇到了一个特别棘手的情况。有个数据表，数据量不到2万条，按说查询起来应该是小菜一碟。可实际情况却让人抓狂，每次查询都得花上30到40秒，这时间长得离谱。

为了解决这个问题，团队小伙伴们使出了浑身解数。索引列都加上了，数据类型也检查过没问题，而且完全符合最左匹配原则；表连接也处理得很规范，用小表驱动大表，关联表的数量也没超过3个。可不管怎么优化，查询就是命中不了索引，每次都是全表扫描，就像大海捞针一样，效率低得可怜。

二、字符集“背锅”

经过一番抽丝剥茧的排查，问题的“元凶”终于浮出水面——两个表的字符集不一致。一个表用的是UTF8MB4，另一个表用的也是UTF8MB4？你可能会纳闷，这不是一样嘛，怎么还出问题了？其实，虽然它们名字里都有“UTF8”，但UTF8MB4和UTF8是完全不同的字符集。

UTF8MB4支持存储特殊字符，而UTF8不支持。在进行关联查询时，数据库就得把字符从UTF8转换成UTF8MB4。这一转换可就坏了事，相当于在索引列上使用了convert函数。咱都知道，在索引列上用函数，索引基本就废了，这也就是查询命中不了索引的根本原因。

三、如何揪出问题

有些小伙伴可能好奇，这么隐蔽的问题是怎么发现的呢？一般情况下，我们会用explain命令来查看索引有没有命中。但explain有个局限性，它只能展示一些基本信息，很多关键细节是看不到的。

我给大家推荐一个更好用的方法，就是用explain format=json加上SQL语句。这么操作之后，就能得到详细的执行计划，里面清楚地记录了查询过程中有没有使用函数等关键信息。靠着这个方法，我们才找到了字符集这个“罪魁祸首”。

四、规范很重要

说到底，这个问题本不该出现。在同一个数据库里，各个表的字符集一定要保持一致，字符集的排序规则也不能马虎，表和字段都得统一规范。要是前期不注意这些细节，后续查询优化的时候可就有得头疼了。

希望大家通过我的这次“踩坑”经历，能在开发中多留个心眼，别再掉进类似的坑里。要是你在实际开发中也遇到过类似的问题，或者对今天讲的内容有啥疑问，欢迎在评论区留言交流。让我们一起把SQL优化玩得更溜，开发出更高效的数据库应用！