字符串字段=数字字面量必然导致索引失效，因MySQL将对索引列执行CAST转换，破坏B+树有序性，引发全表扫描；数字字段=字符串字面量虽通常可用索引，但存在截断、溢出等语义风险。
字符串字段 = 数字字面量：索引必然失效
这是最危险、最常见、也最容易被忽略的场景。比如 mobile 是 VARCHAR 类型且建了索引，但写成 SELECT * FROM users WHERE mobile = 13812345678，MySQL 实际执行的是 CAST(mobile AS SIGNED) = 13812345678。
关键点在于：被函数包裹的是索引列本身。B+Tree 原始排序结构完全失效，优化器只能全表扫描。
-
EXPLAIN中key为NULL、type为ALL就是明确信号 - 多个不同字符串（如
'123'、'0123'、'123abc'）可能转成同一个数字，索引无法保证等值映射唯一性 - ORM 场景下尤其高发：MyBatis 把
Integer参数直接传给VARCHAR字段，JDBC 不报错，但 SQL 执行时已悄悄转换
数字字段 = 字符串字面量：索引通常可用，但语义风险极高
例如 id 是 INT，写成 WHERE id = '123'，MySQL 会把右边转成整数，id 列本身未被函数处理，B+Tree 还能用。
但这不等于安全——转换发生在优化器阶段，不影响索引路径，却可能严重污染结果集：
-
'123a'被截断为123，查到不该查的行 -
'9223372036854775808'（超BIGINT上限）会溢出或归零，导致漏数据 -
EXPLAIN显示走了索引，但rows异常高，说明内部做了大量隐式校验
DATETIME 字段与字符串比较：格式决定索引生死
created_at 是 DATETIME，写成 WHERE created_at = '2025-01-01' 可以走索引；但换成 '2025/01/01' 或 '2025-01-01 10' 就大概率失效。
原因不是语法错误，而是 MySQL 对非标准格式无法安全推导类型，被迫退化为字符串逐行比对：
- 分隔符不匹配（
/vs-）、精度缺失（缺时分秒）、空格/不可见字符都会触发隐式转换 -
WHERE created_at > '2025-01-01'看似没问题，但如果字段实际存的是'2025-01-01 00:00:00.123'，字符串会被截断为'2025-01-01 00:00:00'，范围查询结果偏移 - MySQL 8.0+ 的
SHOW WARNINGS会提示Warning 1739: Implicit type conversion，必须开启并检查
联合索引中任意一列发生隐式转换：前缀彻底作废
比如联合索引 KEY idx_code_age_name (code, age, name)，写成 WHERE code = 101 AND age = 21，哪怕 age 是 INT、name 是 VARCHAR，只要 code = 101 触发隐式转换，整个最左前缀就崩了。
优化器无法利用 code 的有序性做快速定位，后续 age 和 name 的索引下推也全部失效：
- 不会退化为只用
age或name单列索引（除非它们单独建了索引） - 实际执行计划中
key_len会远小于预期值，比如本该是100却显示1，说明只有第一个字节被用了 - 参数绑定场景更隐蔽：JDBC 驱动可能把 Java
Long自动传成数字，而字段是VARCHAR，连 SQL 文本都看不出问题
真正难防的不是语法错误，而是“看起来跑得通、查得到、还走了索引”，但结果不准、性能随数据量陡降。所有字段类型和传入值必须严格对齐，不能依赖 MySQL 的自动兜底逻辑。
