索引失效之函数操作

1、 条件字段函数操作

mysql> select count(*) from tradelog where month(t_modified)=7;

B+ 树提供的快速定位能力，来源于同一层兄弟节点的有序性。对索引字段做函数操作，可能会破坏索引值的有序性，因此优化器就决定放弃走树搜索功能。注意：优化器并不是要放弃使用这个索引。对比索引大小选择更小的索引。加了 month() 函数操作，MySQL 无法再使用索引快速定位功能，而只能使用全索引扫描。

优化器在个问题上确实有“偷懒”行为，即使是对于不改变有序性的函数，也不会考虑使用索引。比如，对于 select * from tradelog where id + 1 = 10000

2、 隐式类型转换

select * from tradelog where tradeid=110717; tradeid 的字段类型是 varchar(32)，而输入的参数却是整型，所以需要做类型转换。

数据类型转换的规则是什么？有一个简单的方法，看 select “10” > 9 的结果

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

验证结果为1，所以在MYSQL中是将字符串转换成数字 对于优化器来说，上面操作等于select * from tradelog where CAST(tradid AS signed int) = 110717;符合上面规则，对索引字段做函数操作，优化器会放弃走树搜索功能

注意：select * from tradelog where id="83126";该case中，id是int类型，不会导致全表扫描。因为是字符串转整数，所以会先将入参83126转化成数字，在进入索引搜索。

3、隐式字符编码转换

select d.* from tradelog l, trade_detail d where d.tradeid=l.tradeid and l.id=2; 链表查询交易记录标和详情表，通过tradeid关联，tradedetail是utf8编码，tradelog是utf8mb4。 查询分析结果如下：

img

1. 第一行显示优化器会先在交易记录表 tradelog 上查到 id=2 的行，这个步骤用上了主键索引，rows=1 表示只扫描一行
2. 第二行 key=NULL，表示没有用上交易详情表 trade_detail 上的 tradeid 索引，进行了全表扫描

表 trade_detail 里 tradeid 字段上是有索引的，为什么没有使用？因为这两个表的字符集不同，一个是 utf8，一个是 utf8mb4，所以做表连接查询的时候用不上关联字段的索引。那为什么字符集不同就用不上索引呢？

字符集 utf8mb4 是 utf8 的超集，所以当这两个类型的字符串在做比较的时候，MySQL 内部的操作是，先把 utf8 字符串转成 utf8mb4 字符集，再做比较。可以理解为=“按数据长度增加的方向”进行转换。

实际上等同如下写法： select * from trade_detail where CONVERT(traideid USING utf8mb4)=$L2.tradeid.value

连接过程中要求在被驱动表的索引字段上加函数操作，是直接导致对被驱动表做全表扫描的原因。

对比验证select l.operator from tradelog l , trade_detail d where d.tradeid=l.tradeid and d.id=4; 此时转换成select operator from tradelog where traideid =CONVERT($R4.tradeid.value USING utf8mb4);CONVERT 函数是加在输入参数上的，这样就可以用上被驱动表的 traideid 索引。

第一种查询的解决方案：

1. 转换成utf8mb4

2. 修改SQL语句 select d.* from tradelog l , trade_detail d where d.tradeid=CONVERT(l.tradeid USING utf8) and l.id=2;

总结：

对索引字段做函数操作，可能会破坏索引值的有序性，因此优化器就决定放弃走树搜索功能。

参考： 《mysql实战45讲》丁奇