CPU瓶颈定位需先确认CPU使用率是否持续过高，通过top/htop观察%us和%sy是否长期超80%，再结合SHOW PROCESSLIST或pg_stat_activity查高消耗SQL，并用EXPLAIN ANALYZE分析执行计划。
CPU瓶颈定位方法
当SQL数据库
响应变慢，首先要确认是否CPU使用率持续过高。在Linux系统中，可通过top或htop查看整体CPU负载，重点关注%us（用户态）和%sy（内核态）是否长期超过80%。若数据库进程（如mysqld、postgres）占CPU比例异常高，说明SQL执行本身消耗过大。
进一步排查建议：
- 查询当前正在运行的高CPU消耗SQL：MySQL用SHOW PROCESSLIST，PostgreSQL用SELECT * FROM pg_stat_activity WHERE state = 'active'
- 结合执行计划分析：对可疑SQL执行EXPLAIN ANALYZE，关注是否出现全表扫描、临时表、文件排序等高开销操作
- 检查是否存在未加索引的WHERE/JOIN字段、低效函数（如DATE(created_at) = '2025-01-01'）、或大量GROUP BY + ORDER BY组合
内存瓶颈识别与优化方向
内存不足常表现为频繁的磁盘交换（swap）、缓冲池命中率下降、或大量临时表写入磁盘。MySQL中可查Innodb_buffer_pool_hit_rate（理想值应>99%），PostgreSQL则关注shared_buffers利用率及pg_stat_bgwriter中的buffers_checkpoint/buffers_clean指标。
常见内存压力诱因：
- buffer pool或shared_buffers配置过小，无法缓存热点数据，导致反复读盘
- 大量复杂查询生成大结果集，超出sort_buffer或work_mem限制，被迫落盘排序
- 连接数过多且每个连接分配较大内存（如MySQL的tmp_table_size、max_heap_table_size设置偏高）
- 存在内存泄漏类问题，如长期未关闭的游标、未释放的prepared statement（尤其在应用层复用不当）
IO瓶颈判断与关键指标
IO瓶颈通常伴随高iowait、磁盘队列积压、吞吐量饱和。用iostat -x 1观察%util（接近100%表示设备忙）、await（平均IO等待毫秒数，持续>10ms需警惕）、r/s、w/s（IOPS）及rkB/s、wkB/s（吞吐量）。
数据库侧典型IO压力来源：
- 随机读多：缺少合适索引导致大量物理读，或buffer pool太小无法缓存热数据
- 顺序写密集：如高频率INSERT/UPDATE触发redo log、binlog、WAL持续刷盘；checkpoint过于激进也会加重IO
- 大事务或批量导入未分批，一次性产生巨量日志和数据页修改
- 存储本身性能不足：机械盘承载高并发写、RAID配置不合理、云盘IOPS配额打满
综合诊断建议
单一指标异常不等于真实瓶颈，需交叉验证。例如CPU高但iowait也高，可能是IO等待导致线程堆积并推高CPU；内存充足但buffer hit率低，要查是否查询模式突变或缓存被刷空。
推荐快速排查路径：
- 先看系统级：top + iostat + vmstat，锁定是CPU/IO/内存哪一类资源最先吃紧
- 再看数据库级：对应DBMS的性能视图（如MySQL performance_schema、PostgreSQL pg_stat_statements）找出Top SQL
- 最后看SQL级：对Top SQL做执行计划+实际运行时长分解，确认是解析慢、执行慢还是返回慢
- 结合慢日志、错误日志、监控图表（如Prometheus+Grafana）回溯时间线，判断是否与发布、流量高峰、定时任务相关
响应变慢，首先要确认是否CPU使用率持续过高。在Linux系统中，可通过top或htop查看整体CPU负载，重点关注%us（用户态）和%sy（内核态）是否长期超过80%。若数据库进程（如mysqld、postgres）占CPU比例异常高，说明SQL执行本身消耗过大。