隐式转换会导致索引失效，必须显式统一类型；因bpn为VARCHAR而查询用数字，MySQL需逐行转类型，使索引无法使用，EXPLAIN显示type为ALL且出现类型转换警告。
直接结论：隐式转换会让索引失效，必须显式统一类型，不能依赖数据库自动转换。
为什么WHERE bpn = 14000000123会变慢？
字段bpn是VARCHAR(20)，而查询里传的是数字14000000123。MySQL 会把每一行的bpn值转成数字再比对——相当于在字段上加了函数，索引完全用不上。
执行计划里会出现警告：Cannot use ref access on index 'bpn' due to type or collation conversion on field 'bpn'，type变成ALL或index，rows暴涨。
- 应用层传参时没加引号（比如 ORM 自动推断为 int）是最常见源头
- 字段定义和参数类型不一致，但开发时没做类型校验
- 迁移旧系统时字段类型没同步更新，比如从 INT 改成 VARCHAR 后忘了改代码
怎么确认是不是隐式转换惹的祸？
跑一遍 EXPLAIN EXTENDED + SHOW WARNINGS，重点看有没有类型转换警告；再对比 EXPLAIN 中的 key 和 type 字段是否为 NULL 或 ALL。
- 如果
possible_keys有值但key是NULL，大概率是类型不匹配 - 用字符串形式重写条件：
WHERE bpn = '14000000123'，再看EXPLAIN是否用了索引 - 检查
SHOW CREATE TABLE确认字段真实类型，别只信文档或印象
修复方式不止加引号这么简单
光把参数改成字符串只是临时解法。长期来看，要从三处同步处理：
- 应用层确保所有传入该字段的参数都是字符串类型（如 Java 用
String.valueOf()，Python 用str()） - 数据库侧补联合索引（如果还有其他过滤条件），比如
(bpn, isverified)，避免回表 - 如果业务允许且字段语义确实是编号类，考虑反向整改：把字段改为
BIGINT UNSIGNED并加约束，但需评估存量数据和上下游兼容性
容易被忽略的连锁问题
隐式转换常和相关子查询、IN (SELECT ...) 套在一起，导致双重打击：外层字段类型错 + 子查询没走索引。比如 WHERE orders.user_id IN (SELECT id FROM users WHERE phone = 13800138000)，phone 是 VARCHAR，但子查询里传了数字，整个子查询可能被物化失败，变成反复全表扫描。
这种嵌套结构下，单修一端没用——得同时核对子查询中所有比较字段的类型、外层关联字段类型、以及中间 JOIN 条件是否也存在类似问题。
