SQL Server 中需用 SET STATISTICS XML ON 查 ActualCPUms 字段（2016+默认支持），旧版本需启用跟踪标志7412；MySQL和PostgreSQL原生不直接提供SQL级CPU时间，须结合OS工具定位。
SQL Server 中怎么看 STATISTICS PROFILE 里的 CPU 时间
SQL Server 自带的 SET STATISTICS PROFILE ON 能显示执行计划 + 每个算子的实际行数和开销，但不直接暴露 CPU 时间。真正反映 CPU 消耗的是 STATISTICS XML 输出里的 ActualCPUms 属性——它只在 SQL Server 2016+（含 Express）中默认启用，旧版本需开启跟踪标志 7412 或升级。
实操建议：
- 优先用
SET STATISTICS XML ON，执行后在“消息”面板点开 XML 链接，在每个<RelOp>节点里找ActualCPUms字段 - 如果只看到
EstimatedCPU没有ActualCPUms，检查 SQL Server 版本是否 ≥2016；否则改用sys.dm_exec_query_stats关联 DMV 查历史平均值 -
ActualCPUms是单次执行中该算子实际消耗的 CPU 毫秒数，不是百分比，加总后接近整条语句的 CPU 时间（但可能略低于sys.dm_exec_requests中的cpu_time，因含调度开销）
MySQL 怎么查慢查询里的 CPU 占用
MySQL 原生不记录单条查询的 CPU 时间，SHOW PROFILES 和 performance_schema.events_statements_history_long 只提供耗时（TIMER_WAIT），它是 wall-clock 时间，混着 I/O、锁等待、CPU 等所有开销。
实操建议：
- 确认是否启用了
performance_schema：运行SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'performance_schema'，返回ON才有效 - 开启语句级统计：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_statements_history_long' - 查最近高耗时语句：
SELECT SQL_TEXT, TIMER_WAIT/1000000000 AS sec FROM performance_schema.events_statements_history_long ORDER BY TIMER_WAIT DESC LIMIT 5；注意这个sec是总耗时，无法拆出纯 CPU - 真要定位 CPU 密集型查询，得结合系统工具：在执行时用
top -p $(pgrep -f "mysqld")观察 mysqld 进程的 %CPU，再用SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep' ORDER BY TIME DESC匹配线程 ID
PostgreSQL 的 EXPLAIN (ANALYZE, BUFFERS) 为什么没 CPU 字段
PostgreSQL 的 EXPLAIN (ANALYZE) 显示的是每个节点的 Execution Time，这是 wall-clock 时间，且默认不包含 CPU 使用率。它底层依赖 getrusage()，但只在编译时加了 --enable-profiling 才会输出 CPU: user=..., system=... ——绝大多数发行版（包括官方二进制、APT/YUM 包、Docker 镜像）都未启用该选项。
实操建议：
- 别指望
EXPLAIN直接给 CPU，重点看Execution Time和Buffers：若shared hit高但时间长，大概率是 CPU 绑架；若read多，优先优化 I/O - 临时验证某条查询是否 CPU 密集：用
\timing on开启 psql 计时，配合EXPLAIN (ANALYZE, BUFFERS)对比逻辑读与耗时比例；例如 100 万行扫描耗时 800ms 且无磁盘读，基本可判定为 CPU-bound - 生产环境长期监控 CPU，应走 OS 层：用
pg_stat_statements记录total_time，再通过pidstat -u -p $(pgrep postgres) 1抓进程级 CPU 分布，反向关联pg_stat_activity.pid
跨数据库统一查 CPU 开销的现实路径
没有通用 SQL 函数能跨库返回 CPU 时间。各数据库对“CPU”的定义、采集粒度、权限控制完全不同：SQL Server 记录每个算子，MySQL 完全不采，PostgreSQL 依赖编译选项。硬要统一，只能放弃 SQL 层，转向操作系统 + 进程维度。
实操建议：
- 用
pid锁定数据库进程：SQL Server 查sys.dm_exec_sessions的session_id→sys.dm_exec_requests的task_address→ Windows 性能计数器；MySQL/PG 直接从information_schema.PROCESSLIST或pg_stat_activity拿ID，再用ps -o pid,pcpu,pmem,comm -p <pid> - 避免在应用层埋点测 CPU：JDBC/ODBC 驱动只暴露网络往返和结果集解析时间，不穿透到数据库内核调度
- 如果必须归因到 SQL 文本，唯一可靠方式是：开启全量慢日志（如 MySQL
slow_query_log+long_query_time=0），再用pt-query-digest或pgbadger解析，它们会把 OS 级time命令结果映射到 SQL，但仍有 5–10% 误差
真正难的不是查哪个字段，而是理解“CPU 时间”在数据库里从来不是孤立指标——它和缓冲区命中率、锁等待、计划重编译搅在一起。盯着一个数字调优，往往调歪了方向。
