全文整体流程分为五个阶段，如图所示。 1. 确认当前测试环境是否与目标环境对齐性能瓶颈定位的前提是"被测环境与目标环境可比"。若环境本身不对齐（如 CPU 核数、MySQL 关键参数、压测工具版本等存在差异），后续所有瓶颈分析结论都会失真。本章用于在正式压测前完成环境对齐的自检，建议按1.1~ 1.4 顺序逐项核对，全部通过后再进入第 2 章。 1.1 确认部署形态与规格首先确认对比目标所处的部署环境：容器化部署还是物理机部署。若为容器化部署，需进一步明确资源规格，并确认 cgroup cpuset 的配置方式： ●CPU 绑定模式（--cpuset-cpus="0-7"）：显式指定容器可使用的物理 CPU 核编号，限制容器任务只能运行在 CPU 0-7 上。它提供 CPU 亲和性约束，确保容器任务在指定的 CPU 上运行。 ●CPU 共享模式（--cpuset-cpus="0-127" --cpus=8）：允许容器任务在 0-127 范围内调度，同时限制 CPU 时间配额为约 8 个核。与绑定模式各有所长，实际结果取决于 NUMA、任务调度、宿主机干扰、CPU 亲和性等。 cgroup 各资源控制项的作用与配置路径（v1 与 v2 路径不同，读取时需先确认版本）：配置作用 cgroup v1 路径（示例） cgroup v2 路径（示例） cpuset 限制可运行在哪些 CPU cpuset/cpuset.cpus cpuset.cpus CPU quota 限制 CPU 时间配额 cpu/cpu.cfsquotaus cpu.max CPU shares/weight CPU 竞争时的相对权重 cpu/cpu.shares cpu.weight memory limit 内存上限 memory/memory.limitinbytes memory.max blkio/io IO 资源控制 blkio/blkio.throttle.* io.max ●检查： ○部署形态（整机 / docker / 虚拟机）；docker 场景下是否独占 CPU/内存/IO、是否设置 cgroup 限制； ○物理规格：CPU 型号/核数/主频、Socket 数与 NUMA 拓扑（每个 NUMA node 的 CPU 与内存分布）、是否启用超线程、CPU governor、内存容量、NVMe/SATA、网卡速率； ○两台机器做性能对比时，即使 CPU 型号相同，NUMA 拓扑不同（如 64C 单 NUMA vs 64C 双 NUMA）性能也可能明显不同。 ●命令：# 部署形态与资源限制 docker info # docker 场景 cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us # cgroup v1 CPU 配额 cat /sys/fs/cgroup/cpuset/cpuset.cpus # cgroup v1 cpuset cat /sys/fs/cgroup/cpu.max # cgroup v2（配额+周期，如 "800000 100000"） cat /sys/fs/cgroup/cpuset.cpus # cgroup v2 cpuset # 物理机规格与 CPU/NUMA 拓扑 lscpu # 型号/核数/Socket/NUMA/超线程 numactl -H # NUMA 拓扑：每 node 的 CPU 与内存 numastat # NUMA 命中/跨 node 访问统计 free -g ethtool <网卡名> | grep Speed ●预期：形态一致，规格对齐（含 CPU 拓扑与 NUMA 结构）；docker 场景资源配额与目标一致。 cgroup 路径定位补充：上述路径直接读取 /sys/fs/cgroup/...，若进程位于子 cgroup 中，可能读不到实际限制。定位当前进程所属 cgroup 路径：cat /proc/self/cgroup # 查看当前进程所属 cgroup # cgroup v2 可进一步读取实际限制： cat /sys/fs/cgroup$(awk -F: '{print $3}' /proc/self/cgroup)/cpu.max 容器内通常已挂载为根 cgroup，可直接读取上述路径。 ●动作：形态或规格不一致 → 拉齐后再测；若资源受限（如 docker 限制 CPU=8），按受限规格单独归一化对比，不能直接套用整机结果；NUMA 拓扑不一致 → 记录差异，测试结论需注明拓扑前提。 1.2 确认 MySQL 版本与配置部署形态与物理规格对齐后，需进一步确认软件层配置一致。即使硬件完全相同，MySQL 版本或 my.cnf 关键参数不同也会带来数倍性能差异，不能跳过本步直接对比。参数不宜简单要求"完全一致"，建议按对性能的影响程度分三类处理： 1.MySQL 参数必须一致（基准项）：MySQL 版本、存储引擎、事务提交相关参数（innodb_flush_log_at_trx_commit、sync_binlog）、transaction_isolation、binlog_format、gtid_mode、innodb_autoinc_lock_mode； 2.测试数据/负载必须一致（基准项）：数据量、字符集、时区、行格式、关键 SQL（语句类型与比例）； 3.强相关参数（影响项）：innodb_buffer_pool_size、innodb_buffer_pool_instances、innodb_io_capacity、innodb_log_file_size、innodb_thread_concurrency、max_connections、thread pool 配置、innodb_flush_method、log_bin、binlog_group_commit_sync_delay； 4.一般参数：其余配置差异记录即可，结合实际性能现象判断是否需要拉齐。 ●命令：mysqld --version diff <目标 my.cnf> <当前 my.cnf> mysql -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size','innodb_buffer_pool_instances', 'innodb_flush_log_at_trx_commit','sync_binlog','innodb_io_capacity', 'innodb_flush_method','innodb_log_file_size','innodb_thread_concurrency', 'max_connections','transaction_isolation','binlog_format','gtid_mode', 'innodb_autoinc_lock_mode','log_bin','binlog_group_commit_sync_delay')" ●预期：版本一致；必须一致的参数项完全一致；强相关参数逐项对齐并记录。 ●动作：版本不一致 → 结论不可比，拉齐版本后再测；事务提交相关参数差异（如innodb_flush_log_at_trx_commit=1 vs 2，会带来数倍写入性能差异）→ 必须拉齐后再对比；强相关参数差异 → 显式对齐；仅一般参数差异 → 记录后继续，若性能现象与该参数相关再回来拉齐重测。 1.3 确认 sysbench 版本与负载模型 MySQL 配置对齐后，压测工具本身的版本与参数同样会影响结果。不同版本 sysbench 默认行为不同，若不显式覆盖，可能导致两次测试看似相同实则负载模型不一致。真正需要保证一致的是：负载模型一致，而不仅仅是 sysbench 命令字符串相似。确认 sysbench 版本是否一致。sysbench 1.0.20 默认 --rand-type=special，sysbench 1.1.0 默认为 uniform，不支持 special。 ●检查： ○sysbench 版本；--rand-type是否显式指定（避免版本默认值不同）；--db-ps-mode（启用--db-ps-mode=disable可优化性能）；--threads、--time、--tables、--table-size是否一致； ○负载模型：所用 test（oltp_read_only/oltp_read_write/oltp_write_only/point_select等）与语句混合参数（--point_selects、--range_selects、--simple_ranges、--sum_ranges、--order_ranges、--distinct_ranges、--index_updates、--non_index_updates）是否一致； ○使用自定义 Lua workload 时：Lua 脚本文件（对比版本/哈希）、数据库连接参数、事务模型、各类请求比例是否一致。 ●命令：sysbench --version # 对比两侧实际执行的 sysbench 完整命令行（含所有语句混合参数） # 自定义 Lua 脚本时：md5sum <脚本> 对比两侧脚本是否一致 ●预期：版本一致，或版本不同但--rand-type/--db-ps-mode/数据量参数已显式覆盖且一致；负载模型（语句类型与比例）一致。 ●动作：版本不同且未显式覆盖参数 → 用相同版本或显式参数重测；负载模型不一致 → 重测；命令与负载模型均一致 → 进入下一步瓶颈定位。 1.4 确认数据与缓存状态一致前三步对齐了"环境 + 软件 + 工具 + 负载"，但数据状态若不一致，写场景下仍会出现不可比的结果。本步确保每次测试的"输入数据"与"缓存起点"都一致。数据一致性包含两个维度：数据内容（每次测试前从同一份备份导入，避免反复写入导致索引变化）与缓存状态（Buffer Pool / Page Cache 的冷热程度）。两侧缓存策略不一致时结果没有可比性，例如：机器 A 的数据已全部进入 Buffer Pool（warm cache），机器 B 刚启动 MySQL（cold cache），此时直接比较 QPS 没有意义。 ●检查： ○数据内容：确认每次测试前都从同一份备份导入； ○缓存状态：明确本轮测试是Cold Cache Test（冷缓存：MySQL 刚启动 / Buffer Pool 为空）还是Warm Cache Test（热缓存：预热后再测），两侧采用相同策略；记录 MySQL 启动时间与预热方式/时长（如以多少条预热查询或预热多长时间为准）。 ●命令：# MySQL 启动时长（判断冷/热缓存起点） mysql -e "SHOW GLOBAL STATUS LIKE 'Uptime';" # Buffer Pool 已加载页数 / 总页数（判断是否已预热） mysql -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_data';" # Buffer Pool 读请求与物理读（累计值，预热前后取差值可判断预热程度） mysql -e "SHOW GLOBAL STATUS WHERE Variable_name IN ('Innodb_buffer_pool_read_requests','Innodb_buffer_pool_reads');" # 记录预热方式/预热时长/预热查询次数（由现场按实际预热方式记录） ●预期：每次测试前数据内容、索引结构、buffer pool 状态一致；冷/热缓存测试类型明确，且两侧策略相同。 ●动作：未重置数据 → 写场景结果不可比，必须重新导入；冷热策略不一致 → 统一策略（都冷或都预热）后重测；数据与缓存状态均一致 → 可开始正式对比。 2. 确认瓶颈是否位于 client 端环境对齐后进入瓶颈定位阶段。定位顺序遵循"由外向内"原则：先排除 client 端（压测发起方）的连接能力、CPU 与网络瓶颈，再进入 server 端分析。若跳过本章直接排查 server，容易把 client 自身瓶颈误判为 server 性能问题。 2.1 确认连接与线程能力是否达到瓶颈高并发压测中，client 的文件描述符（FD）、TCP 端口与连接建立速率可能先于 CPU/带宽成为瓶颈，需最先排除。 ●检查：FD 是否充足；当前连接数与 TCP 状态分布（是否存在大量 TIME_WAIT）；高并发场景是否存在本地端口耗尽风险；sysbench 线程数与连接数的对应关系（每线程连接数、连接建立速率）。 ●命令：ulimit -n # 当前 shell 的 FD 上限（仅参考，不等于 sysbench 进程实际限制） # 实际查看 sysbench 进程的 FD 限制（ulimit -n 只能看当前 shell，不是 sysbench 进程限制） cat /proc/$(pgrep -x sysbench | head -1)/limits # 或 prlimit --pid $(pgrep -x sysbench | head -1) ss -s # 连接总数概览 ss -ant # TCP 连接状态分布（关注 TIME_WAIT 数量） # 本地端口范围与 TIME_WAIT 相关内核参数（高并发短连接场景关注） sysctl net.ipv4.ip_local_port_range sysctl net.ipv4.tcp_tw_reuse sysctl net.ipv4.tcp_fin_timeout ●预期：FD 充足，连接数稳定，无 TIME_WAIT 大量堆积，连接建立本身不构成瓶颈。 ●动作： ○FD 不足（压测报Too many open files）→可自行处理：调大 ulimit 或降低--threads重测。 ○TIME_WAIT 大量堆积或出现连接失败（can't connect）→可自行处理：先确认是否连接建立速率已达上限，改用长连接或降低建连频率；若仍不改善 →⚠ 需研发/运维介入评估连接复用（连接池）或多 client 分流。 2.2 确认 CPU 是否达到瓶颈 ●检查：sysbench 进程的%CPU是否接近核数上限；各线程是否使某些 CPU 核满负荷；是否存在单核满负荷而总 CPU 未满的情况；观察增加 client 并发后 QPS 是否仍有明显增长，并结合 client CPU、延迟和网络指标判断 client 是否成为限制因素（趋势判断，优先于单一百分比阈值）。 ●命令：top -H -p $(pgrep -x sysbench | head -1) pidstat -p $(pgrep -x sysbench | head -1) -u 1 pidstat -t -p $(pgrep -x sysbench | head -1) 1 mpstat -P ALL 1 vmstat 1 # 趋势观察：逐步增加 --threads，确认 QPS 是否继续增长 # sysbench ... --threads=N --report-interval=1 ... run ●预期：增加--threads时 QPS 是否存在明显的吞吐拐点（而非"持续增长"）；%CPU留有余量（参考 <80%，为系统调度与突发负载预留，避免压测时 client 自身抖动；该值仅为参考，以 QPS 增长趋势为准），各核分布相对均匀。注意：Client CPU 未饱和 ≠ 应该继续增加 threads——也可能在 client CPU 只有 40% 时 QPS 就已达到 server 的能力上限。 ●动作： ○增加并发后 QPS 仍有明显增长 →可自行处理：继续增加--threads探测拐点并记录拐点数据。 ○增加并发后 QPS 不再提升（即使 client CPU 未饱和）→可自行处理：说明 server 或其他环节可能已成为瓶颈，转入第3章 server 端定位。 ○CPU 接近上限且 QPS 不再上升、延迟明显升高 →可自行处理：单 client 已达瓶颈，使用多 client 架构重测。 ○仅单核满负荷、总 CPU 未满负荷 →⚠ 需研发介入：sysbench 线程模型或网络收发异常，需研发评估线程模型或抓包分析。 2.3 确认带宽是否达到瓶颈 client CPU 未到瓶颈并不代表 client 没有问题——网络收发同样可能成为瓶颈，尤其是在高 QPS 小包或大结果集场景。本步检查 client 的网络收发是否接近上限。注：iostat -xmt 1 是块设备（磁盘）统计命令，不输出任何网络流量数据，不能用于网络检查（早期版本此处存在误用）。网络检查使用以下命令。 ●检查：带宽维度——网卡rx/tx速率（Bytes/s）是否接近网卡上限；包速率维度——rxpck/s/txpck/s（pps）是否异常；错误维度——drop / errors / TCP 重传是否上升；CPU 维度——softirq（NET_RX/NET_TX）是否集中在个别核。 ●命令：# 吞吐（rx/tx kB/s 与 pps） sar -n DEV 1 # 错误统计（rx/tx drop、errors） sar -n EDEV 1 # 网卡速率与 ring buffer ethtool <网卡名> ethtool -g <网卡名> # NIC 驱动/硬件计数器（丢包、ring buffer 溢出等） ethtool -S <网卡名> | grep -iE "drop|err|fifo|miss" # 接口级收发/错误/丢包计数 ip -s link # 高网络流量下 softirq 是否集中在个别核（前后两次取差值） cat /proc/softirqs ●预期：带宽、pps、drop/errors、重传、softirq 多维度均无明显压力。带宽占比仅是其中一个维度： ○举例（以 25Gbps 网卡为例）：ethtool eth0输出Speed: 25000Mb/s，理论带宽 25Gbps ≈ 3125MB/s。 ■rxkB/s = 1000000（1000MB/s）→ 1000÷3125 ≈ 32%，带宽维度未到瓶颈。 ■rxkB/s = 100000（100MB/s）→ 100÷3125 ≈ 3%，远未到瓶颈，瓶颈在 server 或其他环节。 ○注意：带宽占比不高（如 25Gbps 网卡只跑 5Gbps）并不能直接证明网络无瓶颈——若为大量小包场景，pps 或 softirq（CPU）可能已先成为限制。 ●动作： ○带宽占比低（如 25Gbps 网卡 <30%），且 pps、drop/errors、重传、softirq 均无异常 →可自行处理：client 侧网络未到瓶颈，转入 server 端定位（第 3 章）。 ○带宽接近网卡上限（≥80%，如 25Gbps 网卡跑到rxkB/s ≈ 2700000，即 2700MB/s ≈ 86%），或 drop/errors 持续上升、TCP 重传明显增长、NET_RXsoftirq 单核打满 →⚠ 需研发/网络介入：client 网络收发已到瓶颈，需评估多 client 分流、升级网卡、协议压缩、开启多队列/RSS 等方案。 3. 若瓶颈位于 server 端排除 client 端连接、CPU 与网络瓶颈后，瓶颈大概率位于 server 端。进入 server 端后不要直接做资源巡检：先用 3.1 确认性能现象（吞吐下降 / 延迟升高 / 延迟抖动 / 错误增加），再按"由浅入深"的层次定位：CPU → IO → 内存 → 锁与并发等待，每一层都会给出向下一层引导的判断条件，避免遗漏或重复排查。后续所有指标都应围绕"性能现象"展开并互相印证，而不是孤立地看资源占用。 3.1 确认性能现象定位瓶颈前先采集并记录性能现象。现象不同，定位方向也不同；缺少现象记录，后续所有资源指标都无法与业务表现关联。 ●检查：压测侧吞吐与延迟（QPS/TPS、latency avg/p95/p99/max、errors）；MySQL 侧 Threads_running、Threads_connected、慢查询增长。 ●命令：# sysbench 结果（压测结束后 summary；压测中可用 --report-interval=1 输出中间统计） # queries: QPS transactions: TPS # latency (avg/p95/p99/max) errors: 错误数 # MySQL 侧并发状态 mysql -e "SHOW GLOBAL STATUS WHERE Variable_name IN ('Threads_running','Threads_connected','Slow_queries')" 注：Slow_queries 等是累计状态变量，必须在压测稳态前后各取一次，看差值/增速，不能只看绝对值；Threads_running/Threads_connected 是瞬时值，可直接看当前值。 ●预期：现象记录完整（吞吐、延迟分位数、错误数、Threads_running），可据此选择定位方向。 ●动作：按现象对齐定位方向： ○QPS 下降 / 不再增长且延迟同步升高 → 资源饱和（3.2 CPU / 3.3 IO）或排队等待（3.5），继续逐层定位； ○延迟抖动（p99 远高于 avg、波动大）→ 优先怀疑刷脏、swap、后台任务、锁竞争，关注 3.3 IO 与 3.5； ○errors 增加 → 优先排查连接问题（回到 2.1）或 server 异常（SHOW PROCESSLIST、error log）； ○现象确认后 → 按 3.2 → 3.3 → 3.4 → 3.5 顺序逐层定位。 3.2 确认 CPU 是否达到瓶颈 ●检查：整体 CPU 与 per-CPU 利用率（是否存在单核满负荷而总 CPU 未满）；mysqld 进程 CPU 与线程级 CPU；run queue 长度与上下文切换；%us（用户态）与 %sy（内核态）占比；是否存在 %iowait 异常升高；并发增加时 QPS 的增长趋势。 ●命令：top -H -p $(pgrep -x mysqld | head -1) # 线程级 CPU，定位单核满负荷的具体线程 pidstat -p $(pgrep -x mysqld | head -1) -u 1 pidstat -t -p $(pgrep -x mysqld | head -1) 1 # mysqld 各线程 CPU mpstat -P ALL 1 # per-CPU 利用率 vmstat 1 # r 列为 run queue，cs 列为上下文切换注：%us（用户态）、%sy（内核态）、%iowait 均为 mpstat/top 输出字段；top 汇总显示 %Cpu(s) 行，mpstat -P ALL 按 per-CPU 显示 %usr/%sys/%iowait。 ●预期：%us 占比较高且 QPS 随并发线性增长，%sy 相对较低，%iowait 接近 0；各核分布相对均衡，run queue 无持续堆积。 ●动作（以趋势判断为主，而非单一阈值）： ○并发增加、QPS 继续增长 →可自行处理：CPU 尚未饱和，继续增加并发探测拐点并记录拐点数据。 ○%us接近核数上限，CPU 继续升高但 QPS 不再增长或下降 →⚠ 需研发介入：CPU 用户态已达瓶颈，需研发评估 SQL 优化、索引优化、减少全表扫描；可配合第 4 章采集 perf 热点数据。 ○%sy异常偏高（如 >30%）→可自行处理：先用vmstat查看cs（上下文切换）和in（中断）是否同步飙升，若仍无法解释，转入 3.3 或第 4 章工具进一步分析。 ○总 CPU 不高但某个 CPU 100%（单核瓶颈）→可自行处理：这是数据库高并发场景的常见定位路径——先用top -H/pidstat -t找到满负荷线程的 TID，再用perf top -p 看进程热点函数，或用perf record -t -g -- sleep 30采样该线程后perf report定位热点（perf top -t在不同版本行为不同，建议用上述经验证命令组合；若perf record -t不支持，可改用perf record -p -g -- sleep 30后在perf report中按 TID 过滤）；若热点为锁/自旋 → 转入 3.5，需研发介入。 ○%iowait持续升高 →可自行处理：将 IO 作为重点假设，进入 3.3 进一步结合await、队列深度、IOPS、吞吐及业务延迟进行确认（%iowait高是进入下一层调查的触发条件，但不能直接等价 IO 瓶颈）。 3.3 确认 IO 是否达到瓶颈若 3.2 中观察到 %iowait 偏高，或 QPS 不随 CPU/并发增长而提升，则需进入 IO 层定位。IO 瓶颈是 server 端最常见的性能天花板，尤其是在机械盘或 SATA SSD 场景下。定位 IO 问题不只看"磁盘 util 高不高"，而是沿 IO 链路分层下钻：MySQL → 系统调用 → 文件系统 → Block Layer → 设备，这样才能回答"IO 慢到底慢在哪里"：层级关注点典型工具 MySQL pending reads/writes、redo 写入 SHOW STATUS / P_S syscall pread/pwrite/fsync strace / perf filesystem Page Cache、dirty pages /proc、tracepoint block 队列深度、合并、延迟 iostat / blktrace / BPF device 设备规格上限、健康度 nvme-cli / SMART 数据库场景下不同文件的 IO 特征完全不同（data file 随机读写、redo log 顺序写 + fsync、binlog 顺序写、temporary file 临时落盘），需区分读写类型分别观察。 ●检查：设备侧——读写分别的r_await/w_await、%util、IOPS、吞吐、aqu-sz（队列深度）、读写比例、IO 大小；MySQL 侧——data file / redo log 的 pending 情况；业务侧——SQL 延迟是否与设备侧await同步升高。 ●命令：iostat -xmt 1 # 重点观察：r/s w/s（IOPS）、rkB/s wkB/s（吞吐）、r_await w_await、 # aqu-sz（队列深度）、%util，并与设备规格上限对比 # MySQL 侧 IO 等待 mysql -e "SHOW GLOBAL STATUS WHERE Variable_name IN ('Innodb_data_pending_reads','Innodb_data_pending_writes', 'Innodb_os_log_pending_writes')" # redo log 写入延迟 # 注：Innodb_os_log_written、Innodb_log_writes 均为累计值， # 必须在压测稳态前后各取一次看差值/增速，不能只看绝对值。 mysql -e "SHOW GLOBAL STATUS WHERE Variable_name IN ('Innodb_os_log_written','Innodb_log_writes')" ●预期：多指标联合判断，不使用单一阈值——%util高但await平稳且 QPS 未受影响，说明设备负载高但不是瓶颈；await升高且业务延迟同步升高才是 IO 瓶颈的典型信号；%util低但await高时不能直接排除 IO 问题（可能是 IO 大小异常、队列配置或其他进程干扰）；MySQL 侧无持续 pending（Innodb_data_pending_*、Innodb_os_log_pending_writes不持续 >0）。 ●动作： ○await升高 +%util接近 100% + IOPS/吞吐接近磁盘规格上限 →⚠ 需研发/运维介入：IO 已达瓶颈，需评估升级磁盘（SATA→NVMe）；可先调大innodb_io_capacity（修改my.cnf后重测验证），硬件升级需运维介入；若 IO 量本身异常大，需研发评估 SQL/索引优化以减少 IO。 ○%util高但await平稳、QPS 未受影响 →可自行处理：设备负载高但非瓶颈，继续排查其他层（3.4 内存 / 3.5 锁）。 ○await高但%util、IOPS 均不高 →可自行处理：沿 IO 链路排查（IO 大小是否异常、是否有其他进程抢占 IO），结合pidstat -d确认 IO 归属进程。 ○MySQL 侧Innodb_data_pending_writes持续增长 →可自行处理：结合 dirty pages、checkpoint/flush 状态以及设备 IO 利用率判断是否存在刷脏压力；若确认设备仍有 IO 能力余量，再评估调整innodb_io_capacity并通过回归测试验证。注意：pending writes >0 本身并不能推出innodb_io_capacity太小，若设备已接近能力上限，盲目调大反而加剧 IO 压力。 ○Innodb_os_log_pending_writes持续存在 →⚠ 需研发介入：进一步区分 redo 写入量、flush/fsync 延迟、日志文件 IO 能力及 checkpoint 压力，再决定是否调整 redo 配置（如innodb_log_file_size、innodb_log_buffer_size）或优化落盘路径；不应直接建立"pending >0 → 调大 innodb_log_file_size"的映射。 3.4 确认内存与 buffer pool 是否达到瓶颈若 3.3 中未发现明显 IO 瓶颈但性能仍不达标，需进一步定位内存层瓶颈。即便 IO 无压力，内存不足也可能成为另一处性能天花板。内存需分两个层面检查——系统内存与 MySQL 内存——避免"free 看可用内存还多 → MySQL 一定没有内存问题"的误判： ●系统内存：MemAvailable、swap、Page Cache、Slab； ●MySQL 内存：Buffer Pool、thread buffers（sort/join buffer）、临时表、连接内存、Performance Schema。 ●检查： ○系统层：是否存在 swap（si/so）；MemAvailable是否持续下降；Page Cache 是否异常增长挤压可用内存。 ○MySQL 层：buffer pool 命中率趋势（是否随测试进行而下降、是否与延迟升高同步）；物理读速率（Innodb_buffer_pool_reads增速）；临时表落盘比例。 ●命令：free -g vmstat 1 # 关注 si/so 是否非零 mysql -e "SHOW GLOBAL STATUS WHERE Variable_name IN ('Innodb_buffer_pool_read_requests','Innodb_buffer_pool_reads', 'Innodb_buffer_pool_pages_dirty', 'Created_tmp_disk_tables','Created_tmp_tables')" # buffer pool 命中率 = 1 - Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests # 观察趋势：压测中周期性采样，看命中率是否下降、物理读增速是否加快 # 注：以上状态变量均为累计值，必须在压测稳态前后各取一次看差值/增速，不能只看绝对值。 # MySQL 内存细项：performance_schema 内存占用 Top 10（5.7/8.0） mysql -e "SELECT * FROM performance_schema.memory_summary_global_by_event_name ORDER BY SUM_NUMBER_OF_BYTES_ALLOC DESC LIMIT 10;" # 连接/线程内存：通过 Threads_% 观察线程数与连接数 mysql -e "SHOW STATUS LIKE 'Threads_%';" ●预期：si/so 为 0（非零说明已发生 swap，性能将断崖式下降）；MemAvailable 稳定；Buffer Pool 命中率保持稳定，并结合 Innodb_buffer_pool_reads 增速、磁盘读延迟和业务延迟综合判断；Created_tmp_disk_tables / Created_tmp_tables 比例低（比例较高说明临时表频繁落盘，需结合 SQL 执行计划、排序/聚合操作及临时表大小配置进一步判断原因）。 ●动作： ○出现 swap（si/so非零）→可自行处理：内存超售，调小 buffer pool 或关闭其他进程后重测，避免 swap 导致性能断崖式下降。 ○命中率持续下降、物理读速率上升且延迟同步升高 →可自行处理：工作集大于 buffer pool，调大innodb_buffer_pool_size后重测；若内存物理不足 →⚠ 需运维介入扩容内存。 ○命中率高但物理读速率仍高、性能不达标 →可自行处理：确认是否为冷缓存（回到 1.4 统一冷/热缓存策略），或转入 3.5 排查锁与并发等待。 ○Created_tmp_disk_tables占比高 →⚠ 需研发介入：SQL 存在大量排序/分组且超出tmp_table_size，需研发优化 SQL；可临时调大tmp_table_size/max_heap_table_size重测验证。 3.5 确认锁与并发等待是否达到瓶颈 CPU/IO/内存三层资源均未到瓶颈，但 QPS 仍上不去时，通常瓶颈在于"资源被等待占用而非被消耗"——即锁与并发等待。等待不只发生在 SQL 层，需分层排查： ●SQL 层锁：行锁、MDL、长事务持锁； ●InnoDB 内部：mutex / rwlock 等待； ●OS 层：futex 等待、上下文切换。特别注意：SQL 层没有明显行锁，并不代表 MySQL 内部没有并发等待——内部 mutex/rwlock 竞争同样会造成"CPU 跑不满、QPS 上不去"。 ●检查：是否存在行锁等待（Innodb_row_lock_waits增长）、MDL 锁等待；Threads_running是否持续升高（连接是否堆积）；SHOW ENGINE INNODB STATUS的SEMAPHORES段是否有大量内部 mutex/rwlock 等待；是否存在慢 SQL 长时间持锁；上下文切换是否异常升高。 ●命令：mysql -e "SHOW GLOBAL STATUS WHERE Variable_name IN ('Innodb_row_lock_waits','Innodb_row_lock_time_avg', 'Threads_running','Threads_connected','Slow_queries')" mysql -e "SHOW ENGINE INNODB STATUS\G" # 重点看 SEMAPHORES 段与 LOCK WAIT # 查看当前锁等待 # 注意：不同 MySQL 版本可用视图存在差异，优先根据目标版本选择对应的 sys / performance_schema 锁等待视图 # - 5.7：information_schema.innodb_lock_waits、sys.innodb_lock_waits # - 8.0：performance_schema.data_locks / data_lock_waits（information_schema.innodb_lock_waits 已废弃） mysql -e "SELECT * FROM information_schema.innodb_lock_waits;" # 5.7 mysql -e "SELECT * FROM sys.innodb_lock_waits;" # 5.7 / 8.0 mysql -e "SELECT * FROM performance_schema.data_lock_waits;" # 8.0 # MDL 锁视图（需开启 performance_schema，5.7/8.0 可用） # 注意：5.7 需确保 performance_schema 已启用且 setup_instruments 中 wait/lock/metadata/sql/mdl 已开启 mysql -e "SELECT * FROM performance_schema.metadata_locks;" # 慢 SQL mysql -e "SHOW PROCESSLIST;" # OS 层等待（上下文切换） vmstat 1 # cs 列 ●预期：Innodb_row_lock_waits不增长或增长缓慢；Threads_running稳定（与 3.1 现象记录对照）；无长时间LOCK WAIT；SEMAPHORES段关注是否存在长时间等待、等待线程数量、等待位置及等待类型，并结合多次采样判断当前是否存在持续内部同步竞争（INNODB STATUS 中很多等待统计本身是累计信息，不宜直接用"持续增长"判断当前等待强度）。 ●动作： ○Innodb_row_lock_waits快速增长 →⚠ 需研发介入：行锁竞争激烈，需研发优化热点行更新、拆分事务、缩短事务持锁时间。 ○MDL 锁等待 →可自行处理：先排查并KILL长事务/慢查询；若反复出现 →⚠ 需研发介入评估是否需调整lock_wait_timeout或优化 DDL 时机。 ○SEMAPHORES段显示内部 mutex/rwlock 等待明显 →⚠ 需研发介入：InnoDB 内部并发竞争，采集 4.3.2 offCPU 火焰图后交研发分析。 ○Threads_running持续升高 →可自行处理：不要直接调大max_connections。Threads_running高通常说明连接在堆积（SQL 执行变慢在排队），按以下顺序定位： 1.SHOW PROCESSLIST确认堆积连接的状态（是否大量Sending data/Waiting for lock）； 2.回到 3.2 / 3.3 / 3.5 前述各项，确认是 CPU、IO 还是锁导致执行变慢； 3.先解决执行慢的根因；若确认是并发不足（CPU、IO 均有余量且单查询不慢、连接在排队），再评估引入连接池或调整max_connections后重测验证。直接调大max_connections可能加剧 CPU 竞争、内存消耗、上下文切换与锁竞争，使性能进一步下降；若排查后仍不改善 →⚠ 需研发介入排查是否存在连接泄漏。 4. 进阶性能分析工具第 3 章已能定位到瓶颈大类（CPU / IO / 内存 / 锁），但若需进一步回答"具体是哪个函数、哪段调用栈消耗了 CPU/IO"，基础 OS 与 MySQL 状态指标已不够用。本章引入 nmon、perf top、火焰图等工具，用于从"大类瓶颈"深入到"微观热点"。深入分析应遵循"假设验证"方法，形成定位闭环，而不是逐个工具轮询：观察现象（3.1） ↓ 提出假设（如：CPU 瓶颈） ↓ 选择能够证伪该假设的指标（CPU 趋势 / perf 热点） ↓ 采集数据（本章工具） ↓ 确认 / 排除 ↓ 提出下一假设（IO / 锁 / …）示例：QPS 下降 → 假设 A"CPU 瓶颈"，用 3.2 + perf 检查 → 排除；假设 B"IO 瓶颈"，用 3.3 + iostat 检查 → 排除；假设 C"锁等待"，用 3.5 + P_S / SHOW ENGINE INNODB STATUS 检查 → 确认，进入优化。本章各工具均服务于上述流程中的"采集数据"环节。 4.1 使用 nmon 进行综合看管/记录与回放 ●检查：CPU 各核占用、%iowait、磁盘 IOPS/吞吐、网络吞吐、内存/swap 使用情况；是否需要长时间录制后离线回放（nmon 支持.nmon文件落盘，便于事后分析）。 ●命令：# 交互式实时查看（按 c/d/n/m/r/t/v 切换视图） nmon # 后台录制 60s、间隔 1s，输出到文件便于事后分析 nmon -f -T -s 1 -c 60 -m /tmp # -f 输出 .nmon 文件 # -T 包含 Top Processes # -s 采样间隔（秒） # -c 采样次数 # -m 输出目录 # 离线回放（nmon analyser，Excel 宏工具） # 将 .nmon 文件导入 nmon analyser 生成图表 ●预期：录制结束后可拿到完整时间序列数据，覆盖压测全周期的 CPU / 磁盘 / 网络 / 进程维度；与top/iostat/vmstat单点观察结论一致。 ●动作： ○仅需单点观察 →可自行处理：使用top/iostat/vmstat即可，无需 nmon。 ○需要长时间趋势分析或事后复盘 →可自行处理：录制.nmon文件，配合 nmon analyser 出图。 ○发现某进程持续占用 CPU/IO →可自行处理：进入 4.2 录制perf.data后提交研发分析。 4.2 使用 perf 定位热点函数（先统计、后采样） nmon 适合观察"宏观趋势/事后复盘"，但无法告诉你是哪个函数在消耗 CPU。使用 perf 时遵循"先统计、后采样"：先用 perf stat 回答"CPU 是否真的在做大量计算、IPC 是否异常、cache miss / 上下文切换 / page fault 是否异常"，再用 perf top/perf record 做函数级定位。 ●检查：perf stat层面——IPC（instructions/cycles）是否异常偏低、cache-misses是否明显、context-switches/page-faults是否异常；perf top层面——MySQL 进程中是否存在明显的热点函数（如buf_page_get、row_search_for_mysql、_malloc、__memcpy_*等），热点是否集中在 InnoDB 内核、SQL 解析、网络收发、还是 glibc 内存分配。 ●命令：# 1. 先统计：回答"CPU 在忙什么量级的问题"（需 root 或 perf_event 权限） perf stat -p $(pgrep -x mysqld | head -1) -- sleep 10 # 关注：context-switches、cpu-migrations、page-faults、 # cycles、instructions（IPC = instructions/cycles）、cache-misses # 2. 实时查看 mysqld 的热点函数（需 root 或 perf_event 权限） perf top -p $(pgrep -x mysqld | head -1) # 仅看用户态（排除内核态干扰，聚焦 MySQL 自身代码） # 注：--no-children 在部分 perf 版本的 perf top 中不支持， # 若报错可改用 perf report --no-children，或直接用 perf top -p PID perf top -p $(pgrep -x mysqld | head -1) --no-children # 同时统计内核态与用户态，按事件数排序 perf top -p $(pgrep -x mysqld | head -1) -e cycles:u,cycles:k # 3. 采样 30s 落盘，供后续绘制火焰图 perf record -F 99 -p $(pgrep -x mysqld | head -1) -g -- sleep 30 perf report -i perf.data ●预期：热点函数分布与预期负载相符（如纯读场景下row_search_for_mysql、buf_page_get占比居前；写场景下log_write、buf_flush_*占比上升）；无明显异常热点（如__GI___libc_malloc占比过高提示内存分配开销异常）。 ●动作： ○录制perf.data并保留perf report截图 →⚠ 需研发介入：由研发解读热点函数分布，不要自行判断"正常业务热点"vs"异常热点"。 ○热点集中在__libc_malloc/__libc_free→⚠ 需研发介入：评估改用 jemalloc/tcmalloc。 ○热点集中在recv/send/内核网络栈 →可自行处理：先回到 2.3 评估带宽，再试启用--db-ps-mode=disable重测。 ○需要可视化分析调用栈 →可自行处理：进入 4.3 生成火焰图 SVG 一并提交研发。 4.3 使用火焰图可视化调用栈热点 perf top 能看到热点函数，但无法直观展示"谁在调用这个函数、调用栈有多深"。当需要与非开发同事沟通、或需要分析复杂调用关系时，火焰图是最直观的可视化工具。本节给出基于 perf 的火焰图通用生成方法，4.3.1（onCPU）与 4.3.2（offCPU）在此基础上仅替换采样事件/工具与输出文件名。 ●检查：哪个（些）函数块最宽（横向宽度 = 采样占比，越宽越热）；热点函数的调用来源（谁在调用它）；该热点属于哪条业务路径；MySQL 内核与 glibc 之间的开销分布。纵向高度只代表调用栈深度，不作为异常判断依据。 ●命令：# 1. 采样（若 4.2 已录制 perf.data 可跳过此步） perf record -F 99 -p $(pgrep -x mysqld | head -1) -g -- sleep 30 # 2. 拉取 FlameGraph 工具集（Brendan Gregg） # https://github.com/brendangregg/FlameGraph git clone https://github.com/brendangregg/FlameGraph.git cd FlameGraph # 3. 生成火焰图 perf script -i perf.data | ./stackcollapse-perf.pl | ./flamegraph.pl > mysqld-flame.svg # 4. 浏览器打开 SVG 文件交互式查看 # - 横轴：函数采样占比（越宽越热） # - 纵轴：调用栈深度（自底向上为调用方向） # - 单击某个函数块可放大该子树 ●预期：热点函数块宽度与其业务负载相符（如纯读场景下row_search_for_mysql、buf_page_get占比居前），无与负载不匹配的异常宽块。 ●动作： ○可自行处理：按上述命令生成mysqld-flame.svg，连同perf.data一并打包提交研发。 ○出现unknown或[unknown]占比较高 →⚠ 需研发/运维介入：缺少符号信息，需运维确认mysqld未被 strip 或安装 debuginfo 包后重新采样。 4.3.1 onCPU 火焰图（定位 CPU 热点） onCPU 火焰图采样"进程在 CPU 上运行时"的调用栈，用于定位计算密集型热点（如 SQL 解析、行查找、内存分配等）。当 %us / %sy 偏高但不确定具体函数时优先使用。 ●检查：哪些函数占用了 CPU 时间；热点是否集中在 InnoDB 行/页操作、SQL 解析、内存分配等。 ●命令：使用 4.3 的通用方法，采样默认cycles事件（仅采集在 CPU 上运行的栈），输出文件改为oncpu.svg：# 采样（若 4.3 已录制 perf.data 可复用） perf record -F 99 -p $(pgrep -x mysqld | head -1) -g -- sleep 30 # 生成 onCPU 火焰图（与 4.3 相同的 pipeline，仅输出文件名不同） perf script -i perf.data | ./stackcollapse-perf.pl | ./flamegraph.pl > oncpu.svg ●预期：热点函数分布与业务负载相符（如纯读场景row_search_for_mysql、buf_page_get居前）；无明显异常热点。 ●动作： ○可自行处理：生成oncpu.svg连同perf.data提交研发。 ○若 onCPU 无明显热点，但 QPS 仍上不去 →可自行处理：转入 4.3.2 采集 offCPU 火焰图，排查等待类瓶颈。 4.3.2 offCPU 火焰图（定位等待类瓶颈） offCPU 火焰图采样"进程离开 CPU（被阻塞/睡眠）时"的调用栈，用于定位等待密集型热点（如 IO 等待、锁等待、网络等待、futex/sleep 等）。当 onCPU 无明显热点但 QPS 上不去时使用，常能直接定位到 io_getevents、futex、recv 等等待点。 ●检查：哪些函数导致了进程离开 CPU；等待是否集中在 IO（io_getevents）、锁（futex、__lll_lock_wait）、网络（recv、poll）。 ●命令：# 标准方案：基于 BCC 的 offcputime（按 off-CPU duration 聚合，需 bcc 工具集） # 注：BCC offcputime 默认输出为人类可读格式，需加 -f 输出 folded（折叠栈）格式才能被 flamegraph.pl 解析 /usr/share/bcc/tools/offcputime -f -p $(pgrep -x mysqld | head -1) 30 > offcpu-stacks.txt ./flamegraph.pl offcpu-stacks.txt > offcpu.svg # 辅助方案：基于 perf sched:sched_switch 事件（记录调度切换事件，需 root / perf_event 权限） # 注意：sched_switch 记录的是调度切换事件，并非标准 offCPU profiling。 # 标准 offCPU 需按线程离开/重新获得 CPU 的时间计算 off-CPU duration 后再按调用栈聚合。 # 此方案更适用于分析线程调度/阻塞路径，不与 BCC offcputime 完全等价。 # sched_switch 是 tracepoint 事件，-F（采样频率）对 tracepoint 无意义，应去掉。 perf record -p $(pgrep -x mysqld | head -1) -g -e sched:sched_switch -- sleep 30 perf script -i perf.data | ./stackcollapse-perf.pl | ./flamegraph.pl > sched.svg # 浏览器打开 offcpu.svg 查看 # - 横轴：函数离开 CPU 的采样占比（越宽表示在该函数上等待越久） # - 纵轴：调用栈深度（栈顶即为阻塞点） ●预期：等待时间分布与业务负载相符；若某单一调用路径占据显著比例，应优先分析（不依赖固定阈值，结合基线、业务模型和优化前后结果判断）。 ●动作： ○解读原则：offCPU 只能说明"线程没有运行"以及相关等待路径，不能仅凭一个等待函数直接确定根因。看到futex只能说明线程在 futex 等待，还需继续确定：谁持有锁、为什么持有这么久、锁竞争发生在哪里（结合 3.5）；同理pread64只说明等待读取路径，需继续向文件系统与块设备层下钻（结合 3.3）。 ○等待集中在io_getevents/pread64→⚠ 需研发/运维介入：IO 等待瓶颈，回到 3.3 确认 IO 硬件是否达上限。 ○等待集中在futex/__lll_lock_wait→⚠ 需研发介入：锁等待瓶颈，回到 3.5 确认行锁/MDL/内部锁情况。 ○等待集中在recv/poll/send→可自行处理：网络收发等待，回到 2.3 评估带宽是否到上限。 ○可自行处理：生成offcpu.svg连同perf.data/offcpu-stacks.txt一并提交研发。 4.3.3 onCPU / offCPU 组合定位思路场景优先使用定位方向 %us / %sy 偏高，CPU 被打满 onCPU 火焰图计算热点（SQL/索引/内存分配） CPU 未打满但 QPS 上不去 offCPU 火焰图等待热点（IO/锁/网络）两者均有异常 onCPU + offCPU 组合先消 onCPU 热点，再看 offCPU 是否下降典型定位流程： 1.先看 onCPU 火焰图，若某函数在采样中占据较大比例（结合基线、业务模型和优化前后结果判断，不依赖固定阈值）→ 提交研发优化该函数； 2.若 onCPU 无明显热点 → 看 offCPU 火焰图，找出主要等待点； 3.根据 offCPU 等待类型（IO/锁/网络）回到第 3 章对应章节二次确认，给出具体优化建议。 4.4 工具选用决策 nmon、perf top、火焰图各有适用场景，选错工具会浪费精力且结论不准。工具选择应从"问题类型"出发，而不是按工具逐个尝试。本节给出问题类型 → 工具的映射表，帮助读者快速选取。 ●检查：当前待回答的问题类型（趋势 / 单线程 / 热点函数 / 等待 / 调用栈）；是否有 root / perf_event 权限。 ●命令：无（决策类小节）。 ●预期：按问题类型选择匹配的工具，避免用错工具导致成本高、结论不准。 ●动作：参考下表选取工具：问题类型首选工具 CPU 整体趋势 nmon / mpstat 单线程 CPU 异常 pidstat -t / top -H CPU 热点函数 perf（先 perf stat 后 perf top/perf record） IO 等待 iostat / pidstat -d 系统调用开销 strace / perf 锁等待 P_S / SHOW ENGINE INNODB STATUS / perf 网络吞吐与错误 sar -n DEV/EDEV / ethtool -S 内存 free / vmstat / pidstat -r 长时间趋势、事后复盘 nmon CPU 调用栈热点（onCPU）火焰图（4.3.1）阻塞调用栈（offCPU） offCPU 火焰图（4.3.2）/ offcputime / perf sched 调用栈可视化、需与非开发同事沟通火焰图无 root / perf_event 权限退回使用 top/iostat/vmstat/SHOW GLOBAL STATUS 5. 证据收集清单与反馈模板本章面向现场定位人员在"已确认需提交研发"时，规范需提交的证据范围，避免研发返工要数据。在提交研发前应按以下清单一次性收集齐证据。证据的优先级为：原始数据 > 文本结果 > 截图。优先提交 iostat.log、vmstat.log、perf.data、perf-report.txt、innodb-status.txt 等原始/文本数据（可检索、可二次分析），截图只作为辅助材料。本章最后提供一键采集脚本（5.6一键采集脚本），可自动收集大部分证据。 5.1 基础环境信息（必交） ●检查：部署形态、规格（含 CPU/NUMA 拓扑）、MySQL 版本、sysbench 版本与命令行（含负载模型参数）、数据量。 ●命令：# 部署与规格 docker info 2>/dev/null || echo "非 docker" # 容器资源限制（cgroup v1 / v2 路径不同：v1 分控制器目录，v2 统一挂载） cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us 2>/dev/null # v1 CPU 配额 cat /sys/fs/cgroup/cpuset/cpuset.cpus 2>/dev/null # v1 cpuset cat /sys/fs/cgroup/cpu.max 2>/dev/null # v2（配额+周期） cat /sys/fs/cgroup/cpuset.cpus 2>/dev/null # v2 cpuset # 物理规格与 CPU/NUMA 拓扑 lscpu | grep -E "Model name|^CPU$s$|Thread|Socket|NUMA" numactl -H free -g ethtool <网卡名> | grep Speed # 软件版本 mysqld --version sysbench --version # my.cnf 关键参数（与 1.2 必须一致 + 强相关参数保持同步） mysql -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size','innodb_buffer_pool_instances', 'innodb_flush_log_at_trx_commit','sync_binlog', 'transaction_isolation','binlog_format','gtid_mode', 'innodb_autoinc_lock_mode','innodb_io_capacity', 'innodb_flush_method','innodb_log_file_size', 'innodb_thread_concurrency','max_connections', 'log_bin','binlog_group_commit_sync_delay','tmp_table_size')" # 实际执行的 sysbench 命令行 # （从压测脚本/历史记录中提取，贴完整命令，含负载模型参数） ●预期：信息齐全，可直接复现环境。 ●动作：可自行处理：打包上述输出（文本优先），作为反馈单的"环境信息"附件。 5.2 压测结果与瓶颈定位证据（必交） ●检查：压测 QPS/延迟/错误数；定位到的瓶颈大类；对应小节的命令输出（优先文本日志，截图辅助）。 ●命令：# sysbench 结果（压测结束后的 summary） # 重点贴：QPS、latency avg/p95/p99、errors # server 端 CPU/IO/内存快照（压测稳态时采集 30s，建议重定向到文本文件） top -b -n 6 -d 5 -p $(pgrep -x mysqld | head -1) > top.log # 约 30s iostat -xmt 1 5 > iostat.log free -g > free.log vmstat 1 5 > vmstat.log # MySQL 关键状态（在压测稳态开始与结束各执行一次，取差值） # 注：Innodb_row_lock_waits、Slow_queries、Innodb_buffer_pool_reads 等 # 均为累计值，必须前后各取一次看差值/增速，不能只看绝对值； # Threads_running/Threads_connected 为瞬时值，可单独看当前值。 # —— 稳态开始时采集 —— mysql -e "SHOW GLOBAL STATUS WHERE Variable_name IN ('Innodb_buffer_pool_read_requests','Innodb_buffer_pool_reads', 'Innodb_row_lock_waits','Innodb_row_lock_time_avg', 'Threads_running','Threads_connected', 'Innodb_data_pending_reads','Innodb_data_pending_writes', 'Innodb_os_log_pending_writes','Slow_queries')" > mysql-status-1.txt # ... 压测稳态持续一段时间后 ... # —— 稳态结束时采集 —— mysql -e "SHOW GLOBAL STATUS WHERE Variable_name IN ('Innodb_buffer_pool_read_requests','Innodb_buffer_pool_reads', 'Innodb_row_lock_waits','Innodb_row_lock_time_avg', 'Threads_running','Threads_connected', 'Innodb_data_pending_reads','Innodb_data_pending_writes', 'Innodb_os_log_pending_writes','Slow_queries')" > mysql-status-2.txt ●预期：覆盖"压测结果 + 瓶颈大类 + 关键指标"三部分，开发可据此判断瓶颈方向。 ●动作：可自行处理：按"瓶颈大类"对应章节（3.2确认CPU是否达到瓶颈~3.5确认锁与并发等待是否达到瓶颈）补充该章节的命令输出（文本优先），与本节结果一并提交。 5.3 基线数据（必交）仅凭单点绝对值难以判断问题严重程度，需与基线（Baseline）对比。每次问题单至少记录一份基线数据与一份问题现场数据，并给出变化比例。 ●检查：基准 QPS、基准 latency（avg/p95/p99）、基准 CPU、基准 IOPS/IO latency、基准网络；问题现场的当前值与变化比例。 ●命令：# 使用 5.2 的命令，在"基准态"（如标准机型/历史最优结果）与 # "问题态"（当前待定位环境）各采集一份，按以下格式对比填写： # # QPS： 120k → 92k （-23%） # CPU： 65% → 82% （+17pp） # IO latency： 0.2ms → 1.8ms （9 倍） # p99： 3ms → 15ms （5 倍） ●预期：问题单中至少包含"基线值 → 当前值 → 变化比例"三列，便于研发判断问题严重程度与方向。 ●动作：可自行处理：无历史基线时，用同配置标准环境跑一轮作为基线；对比数据随反馈单一并提交。 5.4 进阶分析数据（按需，涉及 4.x 章节时必交） ●检查：是否已执行 nmon/perf 录制；是否生成火焰图。 ●命令：# nmon 录制文件（4.1） ls -lh /tmp/*.nmon # perf 采样数据（4.2/4.3） ls -lh perf.data # perf report 文本导出（便于开发离线查看） perf report -i perf.data --stdio > perf-report.txt # 火焰图 SVG（4.3/4.3.1/4.3.2，按实际生成的火焰图一并提交） ls -lh mysqld-flame.svg oncpu.svg offcpu.svg sched.svg 2>/dev/null # 注：4.3 产出 mysqld-flame.svg；4.3.1 产出 oncpu.svg； # 4.3.2 产出 offcpu.svg（BCC）与 sched.svg（perf sched）；按实际执行的工具提交 ●预期：文件齐全，开发可离线分析。 ●动作：可自行处理：将.nmon、perf.data、perf-report.txt、火焰图 SVG（mysqld-flame.svg/oncpu.svg/offcpu.svg/sched.svg）一并打包上传。 5.5 反馈单模板提交研发时按以下模板填写反馈单，确保信息完整并形成"定位 → 证据 → 建议 → 验证"闭环：【标题】MySQL 性能瓶颈定位反馈 - <测试场景简述> 【一、环境信息】 - 部署形态： - 规格： - MySQL 版本：<如 8.0.32> - sysbench 版本与命令：<完整命令行，含负载模型参数> - 数据量：【二、影响范围与紧急程度】 - 影响范围：<如：仅压测环境 / 生产某接口 / 全量写入变慢> - 紧急程度： - 复现步骤：<1. ... 2. ... 3. ...，可稳定复现/偶发> 【三、压测结果与基线对比】 - 场景： - QPS：<基线值 → 当前值（变化比例）> - latency avg / p95 / p99：<基线值 → 当前值> - errors：<数值> - 缓存策略：【四、定位结果】（勾选） □ Client 瓶颈 □ Server CPU 瓶颈 □ Server IO 瓶颈 □ Memory 瓶颈 □ SQL/Index 问题 □ Lock/Concurrency 问题 □ Network 问题 □ OS 问题 □ Hardware 问题 □ 暂未定位【五、关键证据】 1. <如：await 0.2ms → 1.8ms，%util 95%，对应 iostat.log> 2. <如：offCPU 火焰图 futex 占比 40%，见 offcpu.svg> 3. <其他关键指标与日志文件> 【六、已尝试的处理】 - <如：已调大 innodb_log_file_size 重测，QPS 无变化> 【七、建议动作】 1. <如：评估 SQL 是否可优化以减少全表扫描> 2. <如：评估升级 NVMe 盘> 【八、验证结果】（优化实施后回归填写） - 优化前：QPS <值>，p99 <值>，<其他关键指标> - 优化后：QPS <值>，p99 <值>，<其他关键指标> - 回归命令：<优化前后使用的同一压测命令，确保可比> - 是否已回滚：<是/否；若回滚，请说明回滚原因与回滚后指标> 【九、附件】（原始数据/文本优先，截图辅助） - [ ] 环境信息输出（5.1） - [ ] 压测结果与瓶颈指标文本日志（5.2） - [ ] 基线对比数据（5.3） - [ ] nmon/perf/火焰图（5.4，按需） - [ ] 一键采集脚本输出目录（5.6，如使用） 5.6 一键采集脚本为避免现场逐条复制命令，可使用一键采集脚本 mysql_perf_collect.sh（与本文档同目录）自动收集本章大部分证据：chmod +x mysql_perf_collect.sh # 首次使用 ./mysql_perf_collect.sh 60 # 参数为采集秒数，默认 60 执行后自动生成带时间戳的证据目录：mysql-perf-20260920-160000/ ├── env/ # 部署形态、cgroup（v1/v2）、CPU/NUMA 拓扑、内存、网卡 ├── mysql/ # 版本、关键参数、STATUS 前后两轮（取差值看趋势）、INNODB STATUS ├── cpu/ # top / mpstat / pidstat（mysqld 线程级） ├── memory/ # free / vmstat ├── io/ # iostat / pidstat -d ├── network/ # sar -n DEV/EDEV、ethtool、ip -s link、softirqs 首末对比 ├── process/ # mysqld 线程快照 ├── perf/ # perf stat 概览（root 且有 perf_event 权限时） └── summary.txt ●动作：可自行处理：将整个输出目录打包，即可作为5.5反馈单模板中【九、附件】的主体；脚本无法覆盖的数据（sysbench summary、火焰图等）按 5.2 压测结果与瓶颈定位证据 (必交) / 5.5反馈单模板手工补充。附录 A：一键采集脚本源码（mysqlperfcollect.sh）以下为 5.6 一键采集脚本的完整源码，便于无法直接获取脚本文件时复制使用。保存为 mysql_perf_collect.sh 后 chmod +x 即可执行；传到 Linux 前请确认换行为 LF。#!/usr/bin/env bash # ============================================================================= # mysql_perf_collect.sh - MySQL 性能瓶颈定位一键证据采集脚本 # 配套文档: MySQL 性能瓶颈定位分析.md（第 5 章） # # 用法: # chmod +x mysql_perf_collect.sh # ./mysql_perf_collect.sh [采集秒数] # 默认 60s # # 说明: # - 建议 root 执行（perf / 部分 ethtool 计数需要权限） # - mysql 采集依赖客户端可免密连接（mysql -e "SELECT 1" 可成功）； # 如需指定账号推荐使用 defaults-extra-file（避免密码进入 shell 环境/进程信息）： # MYSQL_CMD="mysql --defaults-extra-file=/path/to/my.cnf" ./mysql_perf_collect.sh 60 # 或交互式输入密码（不在命令行明文写密码，避免特殊字符解析与历史记录泄露）： # MYSQL_CMD="mysql -u root -p" ./mysql_perf_collect.sh 60 # - 输出目录: mysql-perf-<时间戳>/，采集完成后整体打包即可提交研发 # - 注意: 请在压测稳态时执行本脚本，采集的才是"瓶颈现场"数据 # ============================================================================= set -u # 不启用 set -e：避免单条采集命令失败中断整体采集；关键失败写入 errors.log DURATION="${1:-60}" INTERVAL=5 SAMPLES=$(( DURATION / INTERVAL + 1 )) TS=$(date +%Y%m%d-%H%M%S) OUT="mysql-perf-${TS}" MYSQL_CMD=${MYSQL_CMD:-mysql} for d in env mysql cpu memory io network process perf; do mkdir -p "${OUT}/${d}" done ERRLOG="${OUT}/errors.log" # 检查 mysql 客户端与连接 MYSQL_OK=0 # 若 MYSQL_CMD 含 -p 且当前非交互式终端，密码提示会挂起采集，提前告警 # 注：匹配 -p 作为独立参数，避免误匹配路径中的 -p if echo " ${MYSQL_CMD} " | grep -qE ' -p( |$)' && [ ! -t 0 ]; then echo "警告: MYSQL_CMD 含 -p 且非交互式终端，密码提示可能导致脚本挂起；建议改用 --defaults-extra-file" | tee "${ERRLOG}" fi if command -v "${MYSQL_CMD%% *}" >/dev/null 2>&1; then ${MYSQL_CMD} -e "SELECT 1" >/dev/null 2>&1 && MYSQL_OK=1 fi snap() { # snap <输出文件> <命令字符串> —— 单次快照，记录命令与输出 # 注：使用 bash -c "$*" 解析命令，仅用于本脚本内可信的命令字符串，不直接拼接外部用户输入 local f="$1"; shift { echo "\$ $*"; bash -c "$*"; echo; } >> "$f" 2>&1 } have() { command -v "$1" >/dev/null 2>&1; } echo "[$(date '+%F %T')] 开始采集: 时长 ${DURATION}s, 采样间隔 ${INTERVAL}s" echo "输出目录: ${OUT}/" [ "${MYSQL_OK}" = "0" ] && echo "警告: mysql 不可用（客户端缺失或无法连接），跳过 mysql/ 目录采集" # ---------------------------------------------------------------- env E="${OUT}/env" snap "${E}/deploy.txt" "docker info 2>/dev/null | head -40 || echo '非 docker 环境'" snap "${E}/cgroup.txt" "echo '-- cgroup v1 --'; cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us 2>/dev/null; cat /sys/fs/cgroup/cpuset/cpuset.cpus 2>/dev/null; echo '-- cgroup v2 --'; cat /sys/fs/cgroup/cpu.max 2>/dev/null; cat /sys/fs/cgroup/cpuset.cpus 2>/dev/null" snap "${E}/cpu.txt" "lscpu" snap "${E}/numa.txt" "numactl -H 2>/dev/null || echo 'numactl 未安装'" snap "${E}/numastat.txt" "numastat 2>/dev/null || true" snap "${E}/memory.txt" "free -g" snap "${E}/nic.txt" "ip -o link" snap "${E}/kernel.txt" "uname -a; head -3 /etc/os-release" # ---------------------------------------------------------------- mysql（第一轮） M="${OUT}/mysql" if [ "${MYSQL_OK}" = "1" ]; then snap "${M}/version.txt" "${MYSQL_CMD} --version" snap "${M}/variables.txt" "${MYSQL_CMD} -e \"SHOW VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size','innodb_buffer_pool_instances','innodb_flush_log_at_trx_commit','sync_binlog','transaction_isolation','binlog_format','gtid_mode','innodb_autoinc_lock_mode','innodb_io_capacity','innodb_flush_method','innodb_log_file_size','innodb_thread_concurrency','max_connections','log_bin','binlog_group_commit_sync_delay','tmp_table_size','max_heap_table_size')\"" snap "${M}/status-1.txt" "${MYSQL_CMD} -e \"SHOW GLOBAL STATUS WHERE Variable_name IN ('Threads_running','Threads_connected','Slow_queries','Innodb_row_lock_waits','Innodb_row_lock_time_avg','Innodb_buffer_pool_read_requests','Innodb_buffer_pool_reads','Innodb_buffer_pool_pages_dirty','Innodb_data_pending_reads','Innodb_data_pending_writes','Innodb_os_log_pending_writes','Innodb_os_log_written','Innodb_log_writes','Created_tmp_disk_tables','Created_tmp_tables')\"" snap "${M}/processlist.txt" "${MYSQL_CMD} -e 'SHOW FULL PROCESSLIST'" # MySQL error log 路径与最近告警（辅助定位 server 异常） snap "${M}/error-log-path.txt" "${MYSQL_CMD} -e \"SHOW VARIABLES WHERE Variable_name IN ('log_error','log_error_verbosity','general_log','slow_query_log')\"" # 截取 error log 文件末尾 200 行（需有读权限） ERR_PATH=$(${MYSQL_CMD} -Nse "SELECT @@log_error" 2>/dev/null) [ -n "${ERR_PATH}" ] && [ -r "${ERR_PATH}" ] && tail -n 200 "${ERR_PATH}" > "${M}/error-log-tail.txt" 2>/dev/null fi # ---------------------------------------------------------------- 网卡信息 N="${OUT}/network" snap "${N}/ip-link.txt" "ip -s link" # 默认采集全部非 lo 接口；Docker 环境可能存在大量 veth/bridge，现场可按实际业务网卡过滤 # 优先使用现场指定的 NIC_LIST；否则自动识别默认路由网卡；都无则回退采集全部非 lo 接口 # 接口名含 @ifX（如 eth0@if123）时截取 @ 前部分，避免 ethtool 调用失败 DEFAULT_NIC=$(ip route show default 2>/dev/null | awk '{print $5}' | head -1) if [ -n "${NIC_LIST:-}" ]; then NIC_TARGETS="${NIC_LIST}" elif [ -n "${DEFAULT_NIC}" ]; then NIC_TARGETS="${DEFAULT_NIC}" echo "提示: 未指定 NIC_LIST，自动选取默认路由网卡 ${DEFAULT_NIC}（如需采集多网卡请设 NIC_LIST=\"eth0 eth1\"）" else NIC_TARGETS=$(ip -o link show 2>/dev/null | awk -F': ' '{print $2}' | cut -d@ -f1 | grep -v '^lo$') fi for nic in ${NIC_TARGETS}; do snap "${N}/ethtool-${nic}.txt" "ethtool ${nic} 2>/dev/null; echo '---'; ethtool -g ${nic} 2>/dev/null; echo '---'; ethtool -S ${nic} 2>/dev/null | grep -iE 'drop|err|fifo|miss' | head -20" done cp /proc/softirqs "${N}/softirqs-start.txt" 2>/dev/null # ---------------------------------------------------------------- mysqld 进程 # 兼容 MariaDB：优先匹配 mysqld，未命中再匹配 mariadbd PID=$(pgrep -x mysqld | head -1) [ -z "${PID}" ] && PID=$(pgrep -x mariadbd | head -1) P="${OUT}/process" if [ -n "${PID}" ]; then snap "${P}/ps.txt" "ps -T -p ${PID} -o pid,tid,pcpu,pmem,comm | head -40" fi # ---------------------------------------------------------------- 持续采样（后台并行） echo "采样 ${DURATION}s ..." if have iostat; then iostat -xmt ${INTERVAL} ${SAMPLES} > "${OUT}/io/iostat.log" 2>&1 & fi if have vmstat; then vmstat ${INTERVAL} ${SAMPLES} > "${OUT}/memory/vmstat.log" 2>&1 & fi if have mpstat; then mpstat -P ALL ${INTERVAL} ${SAMPLES} > "${OUT}/cpu/mpstat.log" 2>&1 & fi if have sar; then sar -n DEV ${INTERVAL} ${SAMPLES} > "${N}/sar-DEV.log" 2>&1 & sar -n EDEV ${INTERVAL} ${SAMPLES} > "${N}/sar-EDEV.log" 2>&1 & fi if [ -n "${PID}" ] && have pidstat; then pidstat -u -t -p ${PID} ${INTERVAL} ${SAMPLES} > "${OUT}/cpu/pidstat-mysqld.log" 2>&1 & pidstat -d -p ${PID} ${INTERVAL} ${SAMPLES} > "${OUT}/io/pidstat-mysqld.log" 2>&1 & fi if have top; then # top 输出量较大，单独限制采样次数与间隔（避免 ${SAMPLES} 过多导致输出过大） TOP_SAMPLES=$(( DURATION / 10 + 1 )) top -b -n ${TOP_SAMPLES} -d 10 > "${OUT}/cpu/top.log" 2>&1 & fi if have perf && [ "$(id -u)" = "0" ] && [ -n "${PID}" ]; then # perf stat 时长可参数化，默认 10s；如需覆盖完整窗口可设 PERF_STAT_DURATION=${DURATION} PERF_STAT_DURATION=${PERF_STAT_DURATION:-10} perf stat -p ${PID} -- sleep ${PERF_STAT_DURATION} > "${OUT}/perf/perf-stat.txt" 2>&1 & fi wait # ---------------------------------------------------------------- 收尾快照 cp /proc/softirqs "${N}/softirqs-end.txt" 2>/dev/null snap "${N}/ip-link-end.txt" "ip -s link" if [ "${MYSQL_OK}" = "1" ]; then snap "${M}/status-2.txt" "${MYSQL_CMD} -e \"SHOW GLOBAL STATUS WHERE Variable_name IN ('Threads_running','Threads_connected','Slow_queries','Innodb_row_lock_waits','Innodb_row_lock_time_avg','Innodb_buffer_pool_read_requests','Innodb_buffer_pool_reads','Innodb_buffer_pool_pages_dirty','Innodb_data_pending_reads','Innodb_data_pending_writes','Innodb_os_log_pending_writes','Innodb_os_log_written','Innodb_log_writes','Created_tmp_disk_tables','Created_tmp_tables')\"" snap "${M}/innodb-status.txt" "${MYSQL_CMD} -e 'SHOW ENGINE INNODB STATUS\G'" fi # ---------------------------------------------------------------- summary { echo "mysql-perf 采集摘要" echo "时间: ${TS} 时长: ${DURATION}s 主机: $(hostname)" echo "内核: $(uname -r)" echo "mysqld PID: ${PID:-未找到}" echo "mysql 连接: $([ ${MYSQL_OK} = 1 ] && echo OK || echo 不可用)" echo echo "目录说明:" echo " env/ 部署形态、cgroup(v1/v2)、CPU/NUMA 拓扑、内存、网卡" echo " mysql/ 版本、关键参数、STATUS 两轮（取差值看趋势）、INNODB STATUS、PROCESSLIST、error log" echo " cpu/ top / mpstat / pidstat(mysqld 线程级)" echo " memory/ vmstat" echo " io/ iostat / pidstat -d" echo " network/ sar DEV/EDEV、ethtool、ip -s link、softirqs 首末对比" echo " process/ mysqld 线程快照" echo " perf/ perf stat 概览（root）" echo " errors.log 采集过程中的告警/关键失败" echo echo "提示:" echo " - status-1 与 status-2 为采样前后两轮，取差值可观察趋势" echo " - softirqs-start/end 取差值可观察 softirq 分布与增量" echo " - perf stat 默认采集 10s（PERF_STAT_DURATION 可调），与整体窗口（${DURATION}s）可能不一致；需覆盖完整窗口请设 PERF_STAT_DURATION=${DURATION}" echo " - sysbench summary 与火焰图请按文档 5.2/5.4 手工补充" echo " - 网卡默认采集默认路由网卡；多网卡请设 NIC_LIST=\"eth0 eth1\"" } > "${OUT}/summary.txt" echo "采集完成: ${OUT}/" echo "请将整个目录打包，随反馈单（文档 5.5 模板）提交研发。"