MySQL在WHERE条件类型不匹配时会对索引列执行CAST隐式转换，破坏B+树索引有序性；防护需应用层严格匹配类型并用SQL审计拦截，EXPLAIN可辅助识别。
WHERE条件类型不匹配时，MySQL会在索引列上套CAST
只要查询条件的值和字段类型不一致，MySQL就可能对索引列执行隐式转换——不是把参数转成字段类型，而是把整列数据逐行转成另一类型再比对。比如phone是VARCHAR，却写WHERE phone = 13800138000，实际等价于WHERE CAST(phone AS SIGNED) = 13800138000。
这个CAST操作破坏了B+树索引的有序性前提：索引是按原始字符串排序的，但CAST后数值大小顺序和字符串字典序完全不同（比如'2' > '10'，但数字上2
-
EXPLAIN里type变成ALL、key为NULL，就是最直接信号 - 哪怕表只有几百行，逻辑上也等同于全表扫——因为索引路径彻底不可用
- MyBatis用
${id}拼接时最容易踩坑，#{id}能防但不保万无一失（旧驱动或手动SQL仍可能绕过）
int字段传字符串不一定失效，但varchar传数字一定失效
方向不同，后果不对称：id = '123'（id是INT）通常还能走索引；但code = 123（code是VARCHAR）必然失效。
原因在于转换时机和位置：前者是把字面量字符串转成整数，发生在优化器阶段，不碰索引列；后者是把每一行的code值都转成数字，强制在索引列上加函数，B+树直接作废。
- 看似“加不加引号只是风格问题”，实则是是否触发列级计算的关键分界
-
'123abc'这种非法字符串转INT会变成0，查不到数据但EXPLAIN可能显示用了索引——结果错+性能假象，更危险 - 联合索引如
(code, status)，只要code = 123一出错，整个前缀失效，status也跟着没法下推
字符集或排序规则不一致会让JOIN索引失效
两张表JOIN时，如果关联字段字符集不同（比如一张是utf8mb4，另一张是utf8），或者排序规则冲突（如utf8mb4_unicode_ci vs utf8mb4_general_ci），MySQL无法直接用索引做归并连接或哈希匹配。
它会退化为嵌套循环，并在每次JOIN前临时转换字段值，相当于给索引列加了隐形CONVERT()。
-
SHOW CREATE TABLE看真实字符集，别信建表语句注释或ORM映射里的“看起来一样” -
EXPLAIN中Extra出现Using where; Using join buffer，大概率是这类问题 - 前端传参是字符串、后端没校验就直塞SQL，或者日志脚本硬编码
status = '1'而数据库里status是TINYINT，都是高发场景
MySQL 8.0没禁用隐式转换，别靠版本升级兜底
MySQL 8.0 默认行为和5.7几乎一致，sql_mode里不显式开启STRICT_TRANS_TABLES加特定组合，就不会报错——只会默默全表扫。
官方文档明确说类型转换优先级仍是「数字 > 日期 > 字符串」，这意味着只要一边是数字，MySQL就倾向把另一边转成数字，不管有没有索引。
- 真正有效的防护只有两条：应用层确保传参类型与字段定义严格一致；SQL审计工具拦截
WHERE col = ?类语句，检查绑定参数类型 -
EXPLAIN FORMAT=TRADITIONAL看key_len和ref字段：如果key_len明显小于索引定义长度，或ref是const但rows接近总行数，八成是隐式转换在作祟 - 最隐蔽的坑往往藏在“没报错”的地方——它不让你编译失败，只让你上线后突然慢十倍
