前言

在数据库中，索引失效会导致查询无法利用索引来加速，从而降低查询性能。

今天就来探索为什么隐式类型转换，会导致索引失效呢，为什么不能对参数进行类型转换再匹配呢，这样不就能用上索引呢？

隐式类型转换之谜👓

为什隐式转换会导致索引失效

先看一个例子： create_by 的字段类型为 varchar

看到这儿可能很多人都会大吃一惊！
MySQL 会尝试将 VARCHAR 类型的 create_by 字段值转换为数字类型，然后再与 116 进行比较。在转换过程中，MySQL 会从字符串的开头开始解析数字，直到遇到非数字字符为止。如果字符串开头没有有效的数字，那么转换结果为 0

上面的SQL 和 下面这个SQL 执行逻辑应该是相似的
SELECT distinct create_by FROM t_message WHERE CONVERT(create_by, SIGNED) = 116;
换成这个SQL我想大家都明白了，为什么索引会失效了，隐式转换的时候如果是对列转，那么索引就一定失效

隐式转换索引一定失效么？转换一定是转列么？

当然不是🏍，请看下面ID是bigint,并且执行执行计划是 使用了主键索引的

再来看一张人大金仓的explain, 它这个就很清楚了，是把参数转换成 数据库列的类型，这样就肯定走索引呢 ： id = '123' ::bigint 如下

隐式转换有什么规则呢？什么时候转参数，什么时候转列

🚀其实Mysql转换是有一套优先级的: 数字类型 > 时间类型 > 字符串类型，低级向高级转换。

🚀所以如果列类型的优先级高于参数类型的优先级 那么就会对参数进行类型转换，这时候类型转换不会对性能有啥影响。反之会去对列数据进行转换，性能的影响就比较大

最近工作也遇到很多 数字 和 boolean 类型的转换，在人大金仓中是 将boolean类型转为数字，mysql 没做测试，应该也是一样。

为什么不能直接对参数转换了，这样就不会导致索引失效了❓

MySQL在处理类型不匹配的比较时，通常选择转换列值而非参数值，从而导致索引失效。这个设计决策背后主要是按照

✔MySQL遵循SQL标准中"操作数类型提升"的规则，通常会将低优先级类型转换为高优先级类型，数值类型优先级 > 时间类型 > 字符串类型

这种转换方向是数据库引擎的通用设计模式

为什么SQL标准"操作数类型提升" 要这样设计呢

❗下面看看DeepSeek 是怎么回答的❗

1. 语义一致性（避免歧义）与可预测性

SQL 标准要求表达式的结果类型必须明确且可预测。当操作数类型不同时，通过固定的优先级规则（如数值 > 时间 > 字符串）进行隐式转换，确保所有数据库实现的行为一致。例如：

数值与字符串比较时，字符串转为数值，避免因字符编码差异导致不确定结果。 假设 一个条件是 var_colum = 123, 如果转换成 var_colum = '123' ,那么 ' 123 ' 这种有空格的就无法查询了。这就是语义一致性问题。

2. 计算效率优化

高优先级类型（如数值）通常具有更高效的比较和计算机制。例如：

数值比较直接使用CPU指令，而字符串比较需逐字符处理。优先转为数值可提升性能。

3. 索引结构的限制

我也没咋看懂😭： 索引（如B-tree）按列的原生类型组织。若强制转换参数而非列值，存储引擎仍需按列类型重新转换参数，反而增加开销。例如：

WHERE varchar_col = 123 若转为 varchar_col = '123'，仍需将字符串'123'转回数值与索引比较，无法避免转换。

总结

本篇文章，分析了查询隐式转换什么时候会索引失效，以及转换规则优先级，以及为什么SQL标准要这么去定义，DeepSeek 给的答案是主要就是 避免歧义，提升性能。

推荐阅读：dev.mysql.com/doc/refman/…​

知识扩展

下面第一、二点就是我们今天探索的失效场景

1. 类型不匹配 如果查询条件中的数据类型与索引列的数据类型不一致，数据库可能会进行隐式类型转换，破坏索引的有序性，造成索引失效。

-- 假设 id 是varchar类型的索引列，参数传一个 数字
SELECT * FROM users WHERE id = 123; 

2. 索引列上使用函数或表达式 当在索引列上使用函数、表达式时，数据库无法直接使用索引的有序结构来快速定位数据，通常会导致索引失效。

-- 例如在 MySQL 中，对索引列使用 UPPER 函数
SELECT * FROM users WHERE UPPER(name) = 'JOHN'; 

3. 范围查询右侧列 对于复合索引（多列索引），如果在复合索引的前导列使用范围查询，后续列的索引会失效。

-- 假设存在复合索引 (col1, col2)
SELECT * FROM table_name WHERE col1 > 10 AND col2 = 20; 
-- 此时 col2 列的索引会失效

4. 模糊查询以通配符开头 在使用 LIKE 进行模糊查询时，如果通配符 % 出现在字符串的开头，数据库无法利用索引的有序性进行快速匹配，会导致索引失效。

SELECT * FROM users WHERE name LIKE '%john'; 

5. OR 连接条件 当查询条件使用 OR 连接多个条件，且这些条件部分没有索引或者不全使用同一个索引时，可能会导致索引失效。

SELECT * FROM users WHERE id = 1 OR name = 'john'; 
-- 如果 id 有索引，name 没有索引，可能导致索引失效

6. IS NULL 和 IS NOT NULL 在某些情况下，对索引列使用 IS NULL 或 IS NOT NULL 可能会导致索引失效，尤其是在数据分布不均匀时。

SELECT * FROM users WHERE email IS NULL; 

7. 全表扫描更快 当数据库的查询优化器认为全表扫描比使用索引扫描更快时，会选择全表扫描，此时索引就不会被使用。例如，当查询的数据量占总数据量的比例较大时，优化器可能会做出这样的决策。

8. 索引统计信息不准确 如果索引的统计信息不准确，查询优化器可能会做出错误的决策，导致索引失效。例如，表数据发生了大量的插入、删除、更新操作，但没有及时更新索引统计信息。

9. 强制索引失效 在 SQL 语句中使用 IGNORE INDEX 关键字可以强制数据库不使用指定的索引。

转自https://juejin.cn/post/7490856819003785252