SQL数据库CPU飙高需先定位高开销会话与语句，再分析执行计划、锁等待及配置负载。通过实时会话、执行计划、等待事件和基线对比四步法可快速收敛根因。
SQL 数据库 CPU 飙高，核心要抓“谁在消耗”和“为什么消耗”。先定位高开销会话与语句，再分析执行计划与资源争用，最后结合配置与负载判断是否为设计或运维问题。
查活跃会话与 Top SQL
直接看当前正在运行、且 CPU 消耗高的连接和语句：
- SQL Server：用 sys.dm_exec_requests + sys.dm_exec_sessions 关联查
cpu_time、status、command、sql_handle；配合 sys.dm_exec_sql_text 提取实际 SQL - MySQL：查 SHOW PROCESSLIST 或 performance_schema.threads + events_statements_current，重点关注
PROCESSLIST.STATE和EVENTS.STATEMENT中长时间executing或sending data的语句 - PostgreSQL：查 pg_stat_activity，过滤
state = 'active'且backend_start较新，配合pg_stat_statements（需启用）看累计total_cpu_time排名靠前的查询
看执行计划是否走错路
CPU 高往往意味着大量数据被扫描、计算或排序——执行计划里藏着关键线索：
Browser Session Manager
下载
使用 Playwright 为 jimeng.jianying.com 管理浏览器会话，导入 cookies/localStorage 以自动化视频生成工作流，支持图片上传等功能
- 检查是否有全表扫描（
Table Scan/Seq Scan），尤其在大表上；确认相关字段是否缺失索引或索引未被使用 - 留意嵌套循环（
Nested Loops）驱动表过大、或连接列无索引，导致内层重复执行成千上万次 - 观察是否存在隐式转换（如
WHERE varchar_col = 123）、函数包裹字段（WHERE UPPER(name) = 'ABC'），让索引失效，被迫计算每一行 - 对排序/聚合类语句（
ORDER BY、GROUP BY、DISTINCT），确认是否因内存不足触发磁盘临时文件（Spill to TempDB/External Merge），反复读写放大 CPU 开销
查锁等待与并发瓶颈
表面是 CPU 高，实则可能是线程卡在等待，堆积后引发调度争抢：
- SQL Server：查 sys.dm_os_waiting_tasks，关注
wait_type如LCK_M_XX（锁等待）、PAGEIOLATCH_XX（IO 等待）；若大量会话等同一资源，CPU 可能因自旋或重试升高 - MySQL：查 information_schema.INNODB_TRX + INNODB_LOCK_WAITS，确认长事务阻塞或死锁回滚中的高开销操作
- PostgreSQL：查 pg_locks 和 pg_stat_activity 关联，识别
granted = false的等待链；注意AccessExclusiveLock在 DDL 期间可能阻塞大量查询 - 注意：某些“高 CPU”其实是大量短连接频繁建连/解析/编译 SQL（如未用连接池、硬编码 SQL），此时
SQL Compile或Plan Cache Lookup占比异常高
看配置与负载基线是否合理
排除突发 SQL 后，审视系统水位与设置是否匹配业务节奏：
- 确认最大并行度（
MAXDOP）、并行阈值（COST THRESHOLD FOR PARALLELISM）是否合适；过低导致本可并行的查询串行慢跑，过高则小查询也并行，徒增调度和同步开销 - 检查内存配置（
max server memory/innodb_buffer_pool_size）是否充足；内存不足迫使频繁刷脏页、重读磁盘，间接拉高 CPU（尤其是 IO 密集型场景下的上下文切换） - 对比历史基线：同一时段、同类型业务下 CPU 是否持续偏高？是否伴随应用发版、数据量突增、统计信息过期（导致优化器选错计划）？
- 检查是否有定时任务（如凌晨报表、ETL、备份压缩）或监控脚本（高频轮询
sys视图）在后台悄悄吃 CPU
不复杂但容易忽略。定位从实时会话切入，聚焦 Top SQL 的执行逻辑，再层层剥开锁、配置、负载三层上下文，多数 CPU 飙高都能快速收敛到根因。
