隐式类型转换导致CPU飙升，因MySQL需逐行将字符串字段转为数字计算，无法使用索引，引发全表扫描与高CPU消耗。
直接结论：CPU飙升但EXPLAIN显示全表扫描、且WHERE条件中存在字符串字段与数字参数混用，基本就是隐式类型转换在耗CPU。
为什么隐式类型转换会让CPU飙升
MySQL在执行 WHERE phone = 18600001234（phone 是 VARCHAR）时，会为每一行的 phone 值做一次隐式转数字操作（相当于内部执行 CAST(phone AS SIGNED)），这个转换无法利用索引，又必须逐行计算——20万行就要做20万次字符串解析+数值转换，CPU自然拉满。
这不是“慢查询”，而是“高频短查询+每行强计算”的组合，Slow_queries 计数可能几乎不涨，Threads_running 却持续 >50，vmstat 显示 cs（context switch）异常高。
- 隐式转换本质是给索引列加了不可见函数，优化器直接放弃走索引
- CPU消耗集中在字符串解析、进制转换、错误处理（比如非数字字符转0）
- 数据量越大，CPU压力越线性增长，和索引是否存在无关
如何用EXPLAIN快速识别这类问题
关键不是看 type 是 ALL，而是看 key 是否为 NULL，且 Extra 出现 Using where 而非 Using index condition 或 Using index。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 执行
EXPLAIN SELECT * FROM t_user WHERE phone = 18600001234; - 如果
key列为空，rows接近表总行数，Extra是Using where→ 高概率隐式转换 - 对比执行
EXPLAIN SELECT * FROM t_user WHERE phone = '18600001234';：此时key应显示idx_phone，rows大幅下降
排查时最容易忽略的三个点
很多人查到 EXPLAIN 异常就停了，但真正定位根因还得往下挖两层：
- 应用层传参类型是否和字段定义一致？MyBatis 中
VARCHAR字段就是典型雷区 - SQL里有没有看似“合法”的数字字面量？比如
JOIN ON user.id = order.user_id，但其中一个是INT、另一个是VARCHAR，也会触发转换 - JSON字段提取后参与比较时，
JSON_EXTRACT(...)返回值默认带utf8mb4_bin排序规则，而字符串字面量可能是utf8mb4_0900_ai_ci，规则不匹配同样导致索引失效 + 每行做 collation 转换
确认后怎么快速验证是不是它在作祟
别改代码，先用最轻量的方式交叉验证：
- 在生产只读从库上，用
FORCE INDEX强制走索引：SELECT * FROM t_user FORCE INDEX(idx_phone) WHERE phone = 18600001234;—— 如果响应时间从秒级降到毫秒级，基本坐实 - 用
SHOW PROFILE FOR QUERY N;看 CPU 时间占比：如果executing或converting data占比超高，就是类型转换在吃资源 - 检查
information_schema.COLUMNS中字段类型和应用日志里实际传入的参数类型是否对得上，尤其注意tinyintvsboolean、varcharvsint这类高频错配
真正难的不是发现，而是所有调用方都得同步改——前端、中间件、ORM配置、定时脚本，漏一个就会反复触发。线上紧急止血可以加 SQL_NO_CACHE 配合 FORCE INDEX 临时兜底，但长期必须统一类型契约。
