这些个索引坑，你们是否有踩过呢？( 二 ) _索引

如果规则是“将数字转成字符串”，那么就是做字符串比较，结果应该是0 。

这时，你再看这个全表扫描的语句：
select * from t_tweet where tweet_id=110717;复制代码就知道对于优化器来说，这个语句相当于：
select * from t_tweet where CAST(tweet_id AS tweetId int) = 110717;复制代码也就是说，这条语句触发了我们上面说到的规则：对索引字段做函数操作，优化器会放弃走树搜索功能。
案例三假设系统里还有另外一个表tweet_detail，用于记录帖子的详情数据。

mysql> CREATE TABLE `t_tweet_detail` (  `id` int(11) NOT NULL,  `tweet_id` varchar(32) DEFAULT NULL,  `author_id` int(11) DEFAULT NULL, /* 帖子作者id*/  `tweet_info` varchar(32) DEFAULT NULL, /* 帖子内容 */  PRIMARY KEY (`id`),  KEY `tweet_id` (`tweet_id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;复制代码

这时候，如果要查询id=2的帖子的所有信息，SQL语句可以这么写：
select d.* from t_tweet l, t_tweet_detail d where t1.tweet_id=t2.tweet_id and t2.id=2; 复制代码explain的结果里面第二行的key=NULL表示的就是，这个过程是通过遍历主键索引的方式，一个一个地判断tweet_id的值是否匹配。
表示没有用上帖子详情表t_tweet_detail上的tweet_id索引，进行了全表扫描。
进行到这里，你会发现第3步不符合我们的预期。因为表t_tweet_detail里tweet_id字段上是有索引的，我们本来是希望通过使用tweet_id索引能够快速定位到等值的行。但，这里并没有。
如果你去问DBA同学，他们可能会告诉你，因为这两个表的字符集不同，一个是utf8，一个是 utf8mb4，所以做表连接查询的时候用不上关联字段的索引。
这个回答，也是通常你搜索这个问题时会得到的答案。但是你应该再追问一下，为什么字符集不同就用不上索引呢？
结论是：字符集utf8mb4是utf8的超集，所以当这两个类型的字符串在做比较的时候，MySQL内部的操作是，先把utf8字符串转成utf8mb4字符集，再做比较。
这个设定很好理解，utf8mb4是utf8的超集。类似地，在程序设计语言里面，做自动类型转换的时候，为了避免数据在转换过程中由于截断导致数据错误，也都是“按数据长度增加的方向”进行转换的。
因此，在执行上面这个语句的时候，需要将被驱动数据表里的字段一个个地转换成utf8mb4
这就再次触发了我们上面说到的原则：对索引字段做函数操作，优化器会放弃走树搜索功能。
优化：把t_tweet_detail表上的tweet_id字段的字符集也改成utf8mb4，这样就没有字符集转换的问题了。
原文链接：https://juejin.im/post/6860513755000733709