SQL CPU 飙高的头号原因是查询未走索引导致全表扫描，其次为短连接频繁编译执行计划、统计信息过期、隐式类型转换；需通过执行计划分析、合理建索引、复用连接、更新统计信息及校验参数类型综合优化。
查询没走索引导致全表扫描
这是 SQL CPU 飙高的头号原因。当 WHERE、JOIN 或 ORDER BY 字段缺少有效索引时，数据库只能逐行读取整张表，CPU 要反复做数据解码、条件比对、排序等操作。
实操建议：
- 用
EXPLAIN（MySQL）或EXPLAIN ANALYZE（PostgreSQL）看执行计划，重点确认type是不是ALL（全表扫描），key列是否为NULL - 对高频查询的过滤字段、关联字段、排序字段，组合创建复合索引，注意最左前缀原则
- 避免在索引字段上使用函数或表达式，比如
WHERE YEAR(created_at) = 2024会让索引失效
大量短连接 + 频繁编译执行计划
应用层未复用连接、每次查询都新建连接，会导致数据库反复解析 SQL、生成执行计划、分配内存——这些全是 CPU 密集型操作，尤其在高并发下会明显拖垮 CPU。
实操建议：
- 检查应用连接池配置：最大连接数不宜过大（如 MySQL 默认 151，但实际业务常设 50–100），空闲连接超时时间建议设为 60–300 秒
- 确认是否用了预处理语句（
PREPARE/EXECUTE），它能复用执行计划，避免重复解析 - 观察
Threads_created（MySQL）或pg_stat_database.xact_commit与连接数的比值，若每秒新建连接 > 10，大概率是连接泄漏或未复用
统计信息过期引发劣质执行计划
优化器依赖表的行数、数据分布等统计信息来选执行计划。如果表数据量突增（比如批量导入千万级数据）但未更新统计信息，优化器可能误判，选错索引甚至走嵌套循环而非哈希连接，CPU 就会狂飙。
实操建议：
- MySQL：运行
ANALYZE TABLE table_name；PostgreSQL：运行ANALYZE table_name；SQL Server：用UPDATE STATISTICS - 对频繁变更的大表，可设定时任务每天凌晨自动收集统计信息（注意避开业务高峰）
- PostgreSQL 中，
default_statistics_target默认 100，对倾斜数据可临时调高到 500 再ANALYZE
隐式类型转换强制全字段计算
当 WHERE 条件中字段类型与传入参数不一致（比如 user_id 是 BIGINT，却传了字符串 '123'），数据库会悄悄给字段加类型转换函数，导致索引失效，且每行都要做一次 cast 操作——CPU 使用率直线上升。
实操建议：
- 查慢日志时留意
Rows_examined远大于Rows_sent，再结合EXPLAIN看是否出现Using where; Using index condition以外的额外计算标记 - 应用层严格校验参数类型，ORM 框架（如 MyBatis、Django ORM）注意配置类型映射，避免字符串拼接 SQL
- MySQL 中可通过开启
sql_mode=STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO提前暴露类型不匹配问题
真正难排查的，往往是多个小问题叠加：索引缺失 + 统计信息陈旧 + 应用连接没复用。这时候单看 top SQL 可能看不出异常，得结合 SHOW PROCESSLIST、性能模式表（如 performance_schema.events_statements_summary_by_digest）和操作系统级 CPU 样本交叉验证。
