WHERE条件用数字查VARCHAR字段会导致索引失效，因MySQL将字符串字段隐式转为数字（如CAST(order_sn AS SIGNED)），使索引B+树失效，触发全表扫描；且转换规则粗暴（如'1001A'→1001），引发结果错配与逻辑风险。
WHERE 条件里用数字查 VARCHAR 字段，索引直接失效
这是最常见也最致命的隐式转换场景。比如 order_sn 是 VARCHAR(16)，你写 WHERE order_sn = 1001，MySQL 会把每一行的 order_sn 值都调用 CAST(... AS SIGNED) 转成整数再比较。索引是按原始字符串顺序建的，函数一包，B+ 树就废了——执行计划里 type 变成 ALL，全表扫描启动。
容易踩的坑：
- ORM 框架（如 MyBatis）自动推断参数类型为
Long，生成的 SQL 就是数字字面量，开发根本看不到 - 本地测试数据少，看不出慢；线上百万级订单表一跑就卡住
-
EXPLAIN不会直接告诉你“这里发生了隐式转换”，只显示没走索引，排查容易绕弯
隐式转换不仅慢，还会污染查询结果
字符串转数字的规则很粗暴：从左开始取最长数字前缀，非数字开头直接当 0。所以 '1001A' → 1001，'001' → 1，'abc' → 0。这意味着：
-
WHERE order_sn = 1001实际匹配到'1001'、'1001A'、'1001.5'甚至'1001-2023' -
WHERE mobile = 13800000000可能拉出'13800000000X'和' 13800000000 '（带空格也被截出数字） - 业务上“唯一订单号”查出多条，核对逻辑崩坏，但错误日志里连 SQL 都看起来 perfectly fine
数值字段查字符串常量，反而可能走索引
反过来，如果字段是 INT 类型（比如 user_id），你写 WHERE user_id = '123'，MySQL 通常会把右边的字符串转成整数，而不是给左边加函数。所以索引还能用，type 是 ref，key 显示命中。
但这不等于可以放任：
- 字符串里含非数字字符（如
'123abc'）会被截断为123，和上面一样污染结果 - 超大数字（如身份证号
'530102192005080114'）转成整数会溢出，变成浮点近似值，导致等值匹配失准 - 不同 MySQL 版本对边界情况处理略有差异，升级后行为可能突变
修复动作必须落在应用层和 SQL 层，不能靠 DBA 补救
ALTER TABLE 改字段类型是治本，但多数系统改不了。更现实的做法是堵住源头：
- 所有传参必须和字段类型一致：VARCHAR 字段就传字符串，别让框架或代码自动转
- SQL 中显式加引号：
WHERE order_sn = '1001'，而不是依赖拼接或模板引擎默认行为 - 在 DAO 层统一拦截：对已知 VARCHAR 类型字段（如订单号、手机号），强制 toString() 再绑定
- 上线前必跑
EXPLAIN，重点看key和type是否符合预期，别等慢查询报警才反应
真正麻烦的不是发现不了问题，而是它总在你以为“语法没问题”的地方悄悄生效——一次类型不匹配，既是性能断崖，也是逻辑雪崩。
