隐式类型转换使索引失效，因b+树依赖原始列值有序性；varchar字段传数字不加引号或int字段传字符串带引号，均触发cast/convert，导致全表扫描、type=all、key=null。
隐式类型转换让索引列被“套函数”，B+树直接失效
MySQL 无法在已建索引的列上执行函数或类型转换后仍利用 B+ 树的有序性。一旦发生隐式转换，优化器实际看到的是类似 CAST(phone AS SIGNED) 或 CONVERT(created_at, CHAR) 这样的表达式，而索引只对原始列值有效。这和你手动写 WHERE CAST(phone AS SIGNED) = 13800000000 效果一致——type=ALL、key=NULL 是必然结果。
varchar 字段传数字不加引号是最常见触发点
比如字段 phone VARCHAR(20)，SQL 写成 WHERE phone = 13800000000（无引号），MySQL 就会把每一行 phone 值转成整数再比对。问题不止于性能：
- 前导零丢失：'01380000000' → 转成整数变成 1380000000，匹配失败
- 超长数字截断：'13800000000123456789' 可能溢出为 9223372036854775807（BIGINT 最大值）
- 非数字字符串全转成 0：'abc'、' '、'NULL' 都等于 0，导致误匹配
- EXPLAIN 看不到警告？记得先执行
SHOW WARNINGS，MySQL 8.0+ 会报Warning 1739: Implicit type conversion
int 字段传字符串带引号同样危险
反过来也成立：id INT 字段写成 WHERE id = '123'，MySQL 会把每行 id 转成字符串比较，等效于 WHERE CONVERT(id, CHAR) = '123'。这时即使 id 是主键，也会退化为全表扫描。
尤其要注意这些场景：
- MyBatis 中用
${id}拼接（而非#{id}），引号完全丢失 - 前端传参是字符串，后端没做类型校验就透传给 DAO 层
- 日志脚本或运维 SQL 硬编码写成
status = '1'，但数据库里status TINYINT - 联合索引中任意一列触发隐式转换，整个最左前缀失效，例如
KEY idx_code_age_name (code, age, name)，只要code = 101（code是VARCHAR）就崩
字符集/排序规则不一致会引发更隐蔽的隐式转换
两张表 JOIN 时，若关联字段字符集不同（如一张是 utf8mb4，另一张是 utf8mb3），或排序规则冲突（如 utf8mb4_unicode_ci vs utf8mb4_general_ci），MySQL 会在运行时对字段做临时转换，导致无法使用索引做哈希匹配或归并连接。
排查要点：
- 用
SHOW CREATE TABLE确认真实字符集和 collation，别信注释或 ORM 映射 - JOIN 条件字段必须严格一致：类型 + 字符集 + 排序规则
- EXPLAIN 的
Extra出现Using where; Using join buffer是典型信号 - 表情符号、四字节 UTF-8 字符（如 ?）在
utf8mb3字段里会触发转换甚至截断，查不到数据还扫全表
真正难防的不是语法错误，而是那些“看起来完全合法”的写法：一个引号、一个字符集声明、一次前端透传，就能让索引在千万级数据上彻底失能。线上慢查询里，这类问题往往要靠 EXPLAIN + SHOW WARNINGS + 字段类型交叉核对才能揪出来。
