隐式转换必然导致索引失效，因类型不匹配时MySQL在索引列上执行CAST/CONVERT，破坏B+树有序性，迫使优化器全表扫描；典型表现为EXPLAIN中type=ALL、key=NULL。
直接结论：隐式转换会让索引失效，不是“可能”，而是“必然”——只要 WHERE 或 JOIN 条件中出现列类型与值类型不一致，优化器大概率放弃索引走全表扫描。
WHERE 条件里字符串和数字混用，为什么索引就没了？
MySQL 会把 user_id = '123'（user_id 是 INT）重写成 CAST(user_id AS CHAR) = '123'；SQL Server 则倾向把 customer_id = '1001'（customer_id 是 VARCHAR）转成 CONVERT(INT, customer_id) = 1001。两种写法都等于在索引列上套函数，B-Tree 索引无法跳查。
- 看
EXPLAIN：type是ALL或index（非ref/range），且Extra只有Using where—— 这是典型信号 - 查
SHOW WARNINGS：常能看到Cast(user_id as char)这类提示 - 别信“看起来一样”：
'123'和123在数据库眼里是完全不同的数据路径
JOIN 时字段类型不一致，CAST/CONVERT 不是解药
写成 ON orders.customer_id = CAST(customers.id AS INT) 表面“明确”，实则更糟：每次比较都要对 customers.id 每行做转换，CPU 白耗，且 id 上的索引依然无效——除非你额外建计算列索引，但那是运维成本。
- 真正该做的是统一字段类型：把
customers.id改成INT或BIGINT，同步外键、应用层参数、ETL 脚本 - 改表不可行？用影子表 + 触发器过渡，而不是在 SQL 层打补丁
-
TRY_CAST只适合清洗脏数据（如过滤掉'CUST-123'），不能用于 JOIN 逻辑
应用层传参再规范，也架不住参数类型擦除
Java 用 setString(1, "123") 绑定 INT 字段，JDBC 驱动默认仍发字符串过去；MyBatis 的 #{userId} 若没配 jdbcType=INTEGER，照样触发隐式转换。
- 必须显式调用
setInt(1, 123)，哪怕变量来源是字符串，也先Integer.parseInt()（注意空值和异常） - 连接串加
useServerPrepStmts=true（MySQL 8.0+），让驱动把类型信息透传给服务端 - API 入口层校验：拒绝
"123 "、"123.0"、null，只接受纯整数
JSON 字段里的数字查询，最容易被忽略的陷阱
JSON_EXTRACT(extra_info, '$.age') = '25' 看似合理，但 MySQL 提取结果是数字，却拿字符串去比——引擎会把提取值转成字符串再比，函数索引也白建。
- 正确写法：
JSON_EXTRACT(extra_info, '$.age') = 25（右边用数字字面量） - 若值来自参数，必须用
setInt()绑定，不能setString() - 别依赖
CAST(JSON_EXTRACT(...) AS UNSIGNED)，它同样破坏索引可利用性
最麻烦的不是发现隐式转换，而是它藏在看似无害的字符串拼接、动态 SQL、JSON 解析或跨库关联里——一旦漏掉一个点，整个链路的索引就塌了半边。类型对齐不是 DBA 的事，是每个写 SQL 的人、写 DAO 的人、写 API 的人，得一起守住的底线。
