字符串字段与数字参数比较时索引直接失效：mysql将字符串列隐式转为数字（如cast(string_col as signed)），导致索引无法下推，触发全表扫描；而数值字段与字符串参数比较时索引通常仍可用。
字符串字段与数字参数比较时，索引直接失效
MySQL 在执行 WHERE string_col = 123 这类语句时，不会把右侧的数字转成字符串去匹配，而是把左侧的字符串字段逐行调用隐式转换函数（类似 CAST(string_col AS SIGNED)）转成数字再比较。这意味着：索引无法下推，优化器只能选 type: ALL 全表扫描。
常见现象包括：
- 执行
EXPLAIN显示key为NULL，type是ALL - 查询响应明显变慢，尤其在百万级数据表上
- 实际返回结果可能多于预期（比如
'123abc'和'123'都转成123，全被命中）
数值字段与字符串参数比较，索引通常还能用
反过来写：WHERE int_col = '123'，MySQL 会把字符串常量 '123' 转成整数 123，这个转换发生在优化阶段，不作用于字段本身，所以索引仍可走 ref 或 range。
但要注意边界情况：
- 字符串含非法前缀，如
'abc123'→ 转成0，可能误命中int_col = 0的行 - 字符串超长或溢出，如
'99999999999999999999'→ 转成最大有符号整数9223372036854775807（取决于平台） - 字段是
UNSIGNED类型，而字符串转成负数（如'-123'），会导致匹配不到任何行
隐式转换规则不是“智能推断”，而是机械截取
MySQL 把字符串转数字时，只从左开始读连续数字字符，遇到非数字就停。它不校验格式、不报错、不警告。
典型表现：
-
'123abc'→123 -
' 456 '→456（自动 trim 空格） -
'abc789'→0（开头无数字） -
'0x1A'→0（不识别十六进制前缀）
这种行为在 ORDER BY、GROUP BY、JOIN ON 中同样生效，一旦字段参与这类操作且类型不匹配，就可能触发隐式转换+性能劣化。
真正安全的写法，永远显式对齐类型
别依赖 MySQL 的“自动适配”。该加引号就加，该套函数就套。
- 字符串字段查数字值？→ 写成
WHERE string_col = '123'（前提是业务允许字符串等值） - 必须用数字语义查？→ 改字段类型，或加函数索引（MySQL 8.0+）：
CREATE INDEX idx_num ON t ((CAST(string_col AS UNSIGNED))) - 需要模糊前缀匹配？→ 别用
=，改用LIKE '123%'并确保字段有前缀索引 - 调试时快速验证是否发生转换？→ 查
SHOW WARNINGS，MySQL 5.7+ 在隐式转换时会发Warning级提示
最易被忽略的一点：应用层拼 SQL 时，如果变量未加引号（比如 Python 的 f"WHERE phone = {user_input}"），哪怕传的是数字字符串，也会因缺失引号触发左侧字段转换——这个坑在线上查不出日志，只能靠 EXPLAIN 和慢日志定位。
