1. CPU 与内存瓶颈
1.1 高 CPU 利用率与并发压力
在高并发场景下，CPU 利用率持续偏高，是最直观的性能瓶颈信号之一。CPU 饱和会让大量查询进入排队等待，进而抬高响应时间和事务延迟。通常表现为 Threads_running 持续接近或达到并发上限，以及 Questions、Com_select 等指标的持续高位。这也是为何要把 CPU 与并发匹配的基线建立起来。
排查这类瓶颈时，先从全局状态和当前执行的会话入手，再结合系统级别的采样来判断是否存在资源争用。常用的诊断入口包括进程列表、全局状态、以及 InnoDB 缓存的命中情况。两步走：先确认是否真的进入高并发状态，再定位具体热查询。
以下是实战常用的监控步骤与代码示例，帮助快速定位高 CPU 的根本原因。先查看当前正在执行的查询和等待情况，再结合慢查询分析来定位热点。以下 SQL 片段可用于快速查看关键指标：
SHOW PROCESSLIST;
SHOW GLOBAL STATUS LIKE 'Threads_running';
SHOW GLOBAL STATUS LIKE 'Questions';
此外，通过 性能监控快照，可以发现长时间占用 CPU 的 SQL 模式与执行计划分布。性能基线建立后，能够快速对比得到对应的变化。
对于更深层的诊断，结合性能视图进行聚合分析尤为重要。performance_schema 提供了对语句执行摘要的统计，帮助定位高成本语句及其耗时分布。结合不同 digest 的汇总，可以快速找到热点查询。
SELECT digest, digest_text, count_star, sum_timer_wait/1000000 AS total_ms
FROM performance_schema.events_statements_summary_by_digest
ORDER BY sum_timer_wait DESC
LIMIT 10;
另一个关键点是内存对 CPU 的影响：如果 InnoDB 缓存（bufpool）未能命中，频繁的磁盘 I/O 会导致额外的等待，进而拖慢 CPU 的利用效率。不能只看 CPU，而要综合看内存命中率与 I/O 等待。
在多核服务器上，合理的并发数与查询并发控制策略可以显著降低 CPU 瓶颈。通过合理的连接池配置和 max_connections 的上限设定，避免瞬间大量连接击穿 CPU。
1.2 内存使用与 InnoDB 缓存
内存容量不足或缓存设定不合理，会引发大量页面从磁盘加载，进而影响查询响应时间。需要关注两个核心维度：innodb_buffer_pool_size 与 innodb_buffer_pool_instances 的配置，以及对事务日志、临时表内存的占用。合理的缓存容量能显著降低磁盘 I/O 压力，从而间接缓解 CPU 烫手。
诊断时，先从系统层面的 I/O 与内存页面命中信息入手，再结合 InnoDB 引擎的状态进行判断。下列 SQL 用于查看 InnoDB 的页面命中情况与 I/O 状态，帮助判断缓存是否充分：
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_wait_free';
SHOW ENGINE INNODB STATUS\G
如果 Innodb_buffer_pool_reads 明显高于 Innodb_buffer_pool_read_requests，说明缓存命中率偏低，应该考虑增大缓存容量或调整工作集大小。但请在容量扩展前评估内存可用性，避免系统出现过度分页。
另一个常见的内存瓶颈表现是临时表、排序、哈希等内存分配不足，导致磁盘临时文件创建增多。通过监控 tmp_table_size、sort_buffer_size、join_buffer_size 的配置，以及查询的实际使用情况，可以判断是否需要调整。过大的单个查询内存分配也可能降低并发度，需要权衡。
2. I/O 与存储瓶颈
2.1 磁盘 I/O 与 InnoDB 读写瓶颈
磁盘 I/O 瓶颈通常表现为高等待延迟和大量的随机 I/O 请求。读取/写入延迟、队列深度、以及 IOPS 波动是判断核心。InnoDB 的数据页 / 日志页操作会直接影响到数据库的吞吐与响应。当 I/O 延迟成为关键路径，CPU 与内存优化的效果将大打折扣。
排查要点包括：Innodb_data_reads、Innodb_data_writes、以及系统级的 I/O 延迟。结合 iostat 等外部工具，可以直观观测磁盘的吞吐能力是否落后于请求速率。下列命令用于快速查看 I/O 状态：
iostat -xz 1 5
iostat -dx /dev/nvme0n1 1 5
此外，通过分析 InnoDB 的 I/O 指标，可以确认是否为 数据页命中不足导致的 I/O，还是日志写入成为瓶颈。日志文件的尺寸和写入策略直接影响后续 I/O 行为。
示例 SQL 用以获取 InnoDB 的 I/O 相关全局状态：
SHOW GLOBAL STATUS LIKE 'Innodb_data_reads';
SHOW GLOBAL STATUS LIKE 'Innodb_data_writes';
SHOW GLOBAL STATUS LIKE 'Innodb_log_writes';
如果发现日志写入成为瓶颈，可能需要调整 innodb_log_file_size、innodb_log_buffer_size，以及对事务提交策略进行评估。增大日志文件通常需要 carefully 进行扩容重建日志组。
2.2 磁盘写入放大与日志延迟
日志写入延迟往往与高并发提交密切相关，是 InnoDB 写入通路的关键点。提交延迟与 WAL 日志写入速度直接影响事务吞吐，尤其是在大量小事务场景下更易放大。对日志写入进行专门调优，能带来明显的系统整体改观。
应对方式包括：提前分配足够的 WAL 缓冲区、合并日志写入、并行提交策略，以及监控 innodb_log_writes 与磁盘队列深度。下列查询可用于快速查看相关状态：
SHOW GLOBAL STATUS LIKE 'Innodb_log_writes';
SHOW GLOBAL STATUS LIKE 'Innodb_log_waits';
3. 锁、等待与并发瓶颈
3.1 行锁、死锁与等待时间
在高并发事务环境下，锁竞争和等待时间会显著提升查询延迟。innodb_row_lock_waits 与 innodb_row_lock_time 是反映锁等待的重要指标。若这两项长期高企，需重点排查锁争用源头，如长事务、批量更新、未优化的外键检查等。及时发现死锁并发出预警，是避免性能崩溃的关键。
排查时，SHOW ENGINE INNODB STATUS 能给出当前锁的详细状态及最近的死锁信息。结合全局状态，可以快速定位是哪个语句导致了锁等待。以下是获取锁等待的常用代码：
SHOW GLOBAL STATUS LIKE 'Innodb_row_lock_waits';
SHOW ENGINE INNODB STATUS;
在出现明显锁等待时，对长事务进行分解，避免全表锁的横向扩散，并考虑对热点表增加分区、调整事务粒度、或引入读写分离策略。锁的设计与应用层的事务边界直接决定了并发吞吐量。
3.2 事务隔离级别与并发影响
不同的事务隔离级别对并发和读写一致性有直接影响。较高的隔离级别（如可重复读/串行化）可能增加锁冲突，降低并发吞吐；而较低的隔离级别则可能带来读写不一致的风险。在性能与正确性之间需要权衡取舍。
在排查中，记录当前会话的隔离级别、以及热点查询的锁等待时间，是评估是否需要调整隔离级别的重要步骤。下列 SQL 用于查看全局默认隔离级别与会话级别设置：
SELECT @@global.transaction_isolation AS global_iso;
SELECT @@session.transaction_isolation AS session_iso;
如果锁等待与隔离级别高度相关，考虑在维护窗口期对应用层进行隔离级别的逐步调整，并结合测试基线评估对性能的影响。避免在生产高峰期突然改动，影响系统稳定性。
4. 查询优化与执行计划瓶颈
4.1 慢查询、慢日志与查询分解
慢查询直接反映出执行计划中的低效路径，往往源自未使用索引、选择性差的条件、或非幂等的函数运算。开启慢查询日志并定义合理的阈值，有助于快速聚焦问题子集。慢查询分析是你找到瓶颈最快的入口。
常用的排查流程是：收集慢查询日志、聚合同一 Digest 的执行情况、定位热点 SQL、然后逐个优化。下面的工具和查询在实战中广泛使用：
# 启用慢查询日志（MySQL 配置或运行时）
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
SET GLOBAL long_query_time = 1; -- 1 秒阈值
结合工具进行深度分析，可以获得执行成本的直观证据。pt-query-digest 是 Percona Toolkit 的常用工具，用于从慢日志中提炼热点 SQL 与耗时分布。执行结果经常用于决定哪些查询需要添加、修改索引或改写。下面是一个典型使用示例：
pt-query-digest /var/log/mysql/slow.log > slow_report.txt
4.2 执行计划与索引设计
理解执行计划是定位瓶颈的核心。EXPLAIN 与 EXPLAIN FORMAT=JSON 能够揭示表扫描、索引覆盖、连接顺序等信息。JSON 格式的解释可用于自动化解析与告警。
一个典型的执行计划分析步骤包括：检视是否使用了索引、是否发生文件排序、是否存在临时表，以及连接条件是否可被覆盖索引利用。示例查询用于查看执行计划：
EXPLAIN FORMAT=JSON
SELECT a.col1, b.col2
FROM t1 AS a
JOIN t2 AS b ON a.id = b.id
WHERE a.col3 = 'X' AND b.col4 > 100;
索引设计的目标是让常用查询走覆盖索引路径，尽量避免回表。覆盖索引、前缀索引的选择、以及组合索引的顺序都需要结合实际查询模式进行评估。索引的误用会带来额外的维护开销，甚至降低整体性能。
除了传统的 EXPLAIN 以外，EXPLAIN ANALYZE（MySQL 8.0 及以上版本）可以给出每一步的实际执行代价和时间分布，帮助你更精准地定位瓶颈路径。
实际应用中，结合性能基线与系统日志，对慢查询进行分组、排序和聚类分析，可以把优化焦点放在高收益的查询上，减少全局改动带来的风险。设计可持续的查询优化流程，是长期稳定性的关键。
5. 数据库层面监控与排查方法
5.1 指标采集与基线建立
要实现有效的排查，首先需要建立一套可重复的监控体系，覆盖 CPU、内存、I/O、锁等待、慢查询、连接数等维度，并基于历史数据设定基线阈值。基线能帮助你在异常波动时第一时间发现异常点。
常用的监控组合包括操作系统层面的 iostat、vmstat、sar，以及 MySQL 层面的 SHOW GLOBAL STATUS、performance_schema、和 sys 架构视图。基线建立完成后，你可以通过告警系统在出现异常时快速告警。
# 简单示例：定时采集 MySQL 指标
mysqladmin -u root -p'password' status
mysql -e "SHOW GLOBAL STATUS LIKE 'Threads_running';"
在结构化的监控体系中，云端或本地的可观测性工具（如 Prometheus + Grafana、OpenTSDB、或 ELK 堆栈）可以将上述指标可视化，帮助你在海量数据中发现趋势性问题。可观测性越好，越容易进行快速定位。
5.2 实战工具与排查工作流
排查流程通常包含：收集数据、初步分析、定位热点、验证假设、实施对策、再次验证。sys schema 提供了一组高层次的聚合指标，帮助快速了解系统热点。结合 performance_schema 的细粒度事件统计，可以从语句级别追踪到资源消耗的根源。通过统一的工作流，可以快速从全局到局部完成排查。
SELECT event_name, COUNT_STAR, SUM_TIMER_WAIT/1000000000 AS total_seconds
FROM performance_schema.events_statements_summary_by_digest
ORDER BY total_seconds DESC
LIMIT 5;
SELECT metric_name, value
FROM sys.metrics
WHERE metric_name LIKE 'innodb%';
此外，慢查询日志的系统化分析、以及对执行计划的细化检查，是排查流程的重要环节。借助工具链如 pt-query-digest、pt-query-digest 的产出报告，以及 MySQL 官方的 Explain/Explain Format=JSON，可以实现对热点查询的快速迭代。持续的分析与验证，构成现代数据库运维的核心能力。
