mysql将varchar字段值转为double比较，而非把数字转为字符串，导致索引失效且可能误匹配；正确做法是where条件中字符串字段必须用引号包裹数字字面量。
WHERE条件中VARCHAR字段与数字比较时，MySQL怎么转
MySQL不会把数字转成字符串去匹配，而是把每行的VARCHAR值从左到右截取连续数字部分，转成DOUBLE再比——不是INT，也不是SIGNED。这意味着'123abc'变成123.0，'abc123'变成0.0，' 42 '先trim再转成42.0。
这个转换发生在引擎层扫描前，所以EXPLAIN里type会是ALL，key为NULL，索引直接失效。你查WHERE phone = 13812345678（phone是VARCHAR），实际执行的是“对每一行调用字符串→浮点数转换函数”，再比浮点数。
- 转换方向由类型优先级决定：
STRING ，低优先级往高转 - 不依赖
sql_mode是否开启STRICT_TRANS_TABLES——静默截断在非严格模式下照常发生 - 哪怕只有一行匹配，也得扫全表；因为转换逻辑无法下推到存储引擎的索引查找路径中
IN列表里混用数字字面量和VARCHAR字段的坑
写WHERE object_id IN (844836491101274151, 802909973840527405)，而object_id是VARCHAR(50)，MySQL会把每个数字字面量当成DOUBLE，然后把所有object_id值都转成DOUBLE再逐个比。问题来了：超过DOUBLE精度范围的大整数（如17位以上）会被四舍五入或截断，导致误匹配。
比如'802909973840527405'转DOUBLE可能变成802909973840527398.0，于是WHERE object_id = 802909973840527405会捞出'802909973840527398'这条记录——差7，但你根本没写错。
- 这种误差不可控，且
SHOW WARNINGS未必报错，只在极少数情况下提示Truncated incorrect DOUBLE value -
IN列表越长，转换开销越大，性能雪崩风险越高 - 用字符串字面量重写（
'844836491101274151'）能立刻让索引生效，且结果精确
CAST/CONVERT显式转换为什么不能救索引
有人试过WHERE CAST(status AS SIGNED) = 1，以为能“主动控制转换”，结果发现依然type: ALL。原因很简单：CAST是SQL层函数，必须在Server层逐行计算，无法下推到InnoDB的B+树查找逻辑里。索引只能用于“字段本身”参与等值/范围查找，一旦套了函数，就等于放弃索引。
真正有效的解法只有两个：ALTER TABLE改字段类型，或者改查询写法——让比较值类型跟字段一致。前者治本，后者治标但见效快。
-
CONVERT(col, SIGNED)和col + 0效果一样，都是Server层计算，索引无效 - 如果字段存的是纯数字字符串（如
'1','2'），可先用UPDATE批量转成整型，再改列类型 - 业务代码里拼SQL时，务必检查所有
WHERE条件的值类型是否与字段声明一致
字符集不匹配也会触发隐式转换
两个VARCHAR字段JOIN或比较时，若字符集不同（比如utf8mb4 vs latin1），MySQL会把低优先级字符集的值转成高优先级字符集再比。这个过程不是简单编码映射，而是按字符集规则做转换，可能引发排序规则冲突、乱码，甚至让联合索引失效。
典型表现是EXPLAIN里Extra出现Using where; Using index但rows远高于预期——说明索引虽然被用上，但因字符集转换导致部分过滤逻辑退回到Server层。
- 用
SHOW FULL COLUMNS FROM table_name确认字段字符集，别只看CREATE TABLE语句里的默认值 - 跨库JOIN时尤其危险，因为库级字符集可能不同，字段级又没显式指定
- 修复方式：统一字符集（推荐
utf8mb4），或在JOIN条件里加COLLATE强制指定
EXPLAIN的key和Extra，再立刻SHOW WARNINGS——很多问题就藏在那条被忽略的Warning | 1292里。
