只要让查询值类型和字段类型严格一致，90%的隐式类型转换索引失效问题当场消失；varchar字段传数字不加引号、bigint字段传字符串带引号、join关联字段类型或字符集不一致、存储过程中变量类型声明错位等均会导致索引失效，须统一类型、禁用${}拼接、显式转换参数并启用strict_trans_tables。
只要让查询值类型和字段类型严格一致，90%的隐式类型转换索引失效问题当场消失。
WHERE条件里VARCHAR字段传数字不加引号
这是线上最常见、杀伤力最强的写法。phone是VARCHAR(11)，却写成WHERE phone = 13800138000，MySQL被迫对每行phone做CAST(phone AS UNSIGNED)，B+树跳查能力彻底归零。
现象：EXPLAIN显示type: ALL、key: NULL、rows等于全表行数
- 修复：一律改成
WHERE phone = '13800138000'，单引号不可省 - MyBatis里禁用
${}拼接（如WHERE phone = ${phone}），它会吃掉引号；必须用#{} - 前端传参若为数字类型（如JSON解析后），后端DAO层要显式转成字符串再传入，不能直接拼进SQL
INT/BIGINT字段传字符串带引号
反向操作同样危险。id是BIGINT，却写成WHERE id = '123'，MySQL仍需逐行调用CONVERT(id, CHAR)，旧版本或统计信息不准时，EXPLAIN可能显示type: index而非ref，实际仍是全表扫描。
- 修复原则：保持原生类型，写成
WHERE id = 123 - 如果应用层只能拿到字符串（如HTTP query参数），应在SQL执行前就转成整型，而不是交给MySQL隐式处理
- 别用
CAST(id AS CHAR) = '123'兜底——函数作用于列，索引照样失效
JOIN关联字段类型或字符集不一致
两张表用code关联，但table_a.code是VARCHAR(20)且字符集utf8mb4_unicode_ci，table_b.code是BIGINT或字符集utf8，MySQL无法直接利用索引做等值匹配，退化为嵌套循环+逐行转换。
- 检查命令：
SHOW CREATE TABLE table_a和SHOW CREATE TABLE table_b，对比CHARSET、COLLATE、字段类型 - 首选修复：统一字段类型与字符集，例如执行
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 临时绕过：在无法改表结构时，可用
/*+ USE_INDEX(t1, idx_a) */提示驱动表选择，但治标不治本
存储过程/动态SQL中变量类型声明错位
存储过程中声明DECLARE v_phone VARCHAR(20)，但调用时传入数值字面量，或用CONCAT拼接条件，都会触发隐式转换。
- 变量声明必须对齐字段类型：若字段是
VARCHAR，变量也应为VARCHAR；若字段是INT，变量就该是INT - 禁用
${}拼接和裸CONCAT()构造WHERE子句，优先使用预编译参数占位 -
SELECT @@sql_mode确认是否启用STRICT_TRANS_TABLES，它能让部分隐式转换直接报错，暴露问题
真正难的不是识别类型不匹配，而是当字段类型被ORM自动映射、中间件透传、日志脱敏重写后，原始类型信息早已丢失——这时候得靠EXPLAIN FORMAT=TRADITIONAL + SHOW WARNINGS交叉验证，而不是只看SQL文本长什么样。
