隐式转换导致索引失效，因类型不匹配触发列上CAST/CONVERT操作，破坏B+树有序性，优化器被迫全表扫描；varchar字段传数字不加引号或int字段传字符串虽语法合法，但均会引发该问题。
隐式转换会让 MySQL 放弃使用索引，直接走全表扫描——不是因为语法错，而是类型不匹配时，MySQL 内部做了不可逆的列值转换，破坏了 B+ 树索引的有序性前提。
varchar 列被当成数字比较时，索引必然失效
当查询条件是 WHERE code = 123，而 code 是 varchar 类型时，MySQL 会把每一行的 code 值都转成浮点数再比对。这个转换过程无法下推到索引层，B+ 树没法跳过无效分支，只能逐行计算。
- 例如
'101abc'→ 转为101.0，'102x'→102.0，'abc'→0.0 -
EXPLAIN中会看到type: ALL，key: NULL - 即使表里只有 3 条数据，逻辑上也等价于全表扫；数据量大时性能断崖式下跌
int 列被传入字符串时，多数情况仍能走索引
WHERE id = '123'（id 是 int）通常不会让索引失效，因为 MySQL 会把字符串字面量转成整数，这个转换发生在优化器阶段，不影响索引查找路径。
- 前提是字符串能无损转为整数，如
'123'、' 123 '（自动 trim） - 但
'123abc'或超长数字如'99999999999999999999'可能溢出或转为0，导致结果错误，虽仍用索引但查不到预期数据 - 用
EXPLAIN验证：只要key字段显示索引名，且rows显著小于表总行数，就说明索引生效
联合索引中任意一列发生隐式转换，整个索引前缀失效
比如联合索引 KEY idx_code_age_name (code, age, name)，若写成 WHERE code = 101 AND age = 21，则 code = 101 触发隐式转换，整个索引的最左前缀 code 就作废了，后续 age 也无法利用索引下推。
- 哪怕
age是int、name是varchar，只要最左列code的类型不匹配，索引就退化为只用age或name单列（如果单独建了索引） - 更隐蔽的是参数绑定场景：ORM 传入
Integer给varchar字段，JDBC 驱动可能不报错，但 SQL 执行时已悄悄触发转换 - 排查方法：在慢查询日志里抓出实际执行的 SQL，用
EXPLAIN FORMAT=TRADITIONAL对照看key_len和ref
MySQL 8.0 并未默认禁用隐式转换，别信“升级就安全”
MySQL 8.0 引入了 sql_mode 中的 STRICT_TRANS_TABLES 和更激进的 ERROR_FOR_DIVISION_BY_ZERO，但隐式类型转换本身仍是默认开启行为，仅在极少数严格模式组合下才报错（如 NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES 配合 CAST 显式要求）。
- 官方文档明确说明：类型转换规则在 8.0 和 5.7 中基本一致，优先级仍是「数字 > 日期 > 字符串」
- 真正有效的防护是应用层校验 + SQL 审计：所有传给
varchar字段的值必须是字符串，所有传给int字段的值必须是数字，不能依赖数据库兜底 - 最容易被忽略的一点：JSON 字段、ENUM、SET 类型参与比较时也会触发隐式转换，且行为更难预测，务必单独验证
