隐式类型转换会导致mysql索引失效并引发全表扫描：当where字段与值类型不一致（如varchar字段用数字比较、bigint字段传字符串、datetime字段用数值），mysql需逐行转换数据，破坏b+树有序性，使索引无法使用，查询从毫秒级降至秒级甚至更差。
隐式类型转换会让 MySQL 放弃索引，直接全表扫描，WHERE 条件就从毫秒级变成秒级甚至分钟级。
WHERE 字段和值类型不一致时必然触发隐式转换
比如 user_id 是 VARCHAR 类型，但写成 WHERE user_id = 123（没加引号），MySQL 就会把每一行的 user_id 值都转成浮点数再比较——B+ 树索引没法支持这种动态转换，只能扫全表。
-
id是BIGINT，却传字符串：WHERE id = '123' -
create_time是DATETIME，却用数值：WHERE create_time >= 20240101（触发隐式转时间失败，退化为字符串比对） - ORM 框架里
#{id}传入 JavaLong，但 DB 字段是VARCHAR，也会悄悄转换
EXPLAIN 看不出 UPDATE 是否走索引，得用 SELECT 模拟
MySQL 5.6.2 之前根本不支持 EXPLAIN UPDATE，报错 ERROR 1064 (42000) 不是 SQL 写错了，是版本太低。5.6.2+ 虽支持，但常因统计信息过期或优化器误判导致 type=ALL 却看不出原因。
- 正确做法：用等价的
EXPLAIN SELECT *替代，WHERE条件必须完全一致，且不能有函数包裹（如WHERE DATE(created_at) = '2024-01-01'会失效） - 关键看
type字段：const/ref表示走了索引，ALL就是全表扫 -
key为空 ≠ 没建索引，可能是联合索引最左前缀没满足，比如索引是(a,b,c)，但条件只写了WHERE b = 1
字符集混用也会绕过索引，且不报错
表用 utf8mb4，但连接层用了 latin1，或者两个 JOIN 表字段字符集不同，MySQL 会在运行时做字符集转换，同样绕过索引。这类问题不会报错，但执行计划里会出现 Using where; Using temporary; Using filesort 这种危险组合。
- 验证方法：
SHOW WARNINGS查重写后的 SQL，若看到类似CAST(`t`.`user_id` AS SIGNED)的提示，就是隐式转换被显式化的证据 - 真实影响：主从延迟飙升、CPU 持续 90%+、从库
Seconds_Behind_Master拉到几百秒 - 最容易被忽略的是锁问题：全表扫描更新时，InnoDB 会逐行加 X 锁，哪怕只更新 1 行，也可能锁住几千行
真正难处理的不是“有没有索引”，而是“索引为什么没被用”——隐式转换藏在类型、字符集、ORM 参数、连接配置多个层面，单靠 EXPLAIN 很难一眼定位，必须结合 SHOW WARNINGS 和实际数据类型校验。
