③ 生产环境：机器规划与 sysbench 压测

对应第 05 ~ 08 讲 · 机器配置经验值 · QPS/TPS/IOPS · 压测实战与硬件负载观察

总览 ① 交互与 Server 架构 ② 更新与日志体系 ③ 规划与压测 ④ 监控体系 ⑤ Buffer Pool 结构 ⑥ LRU 与缓存淘汰 执行计划篇 85~108 实战与高可用篇 109~130
机器配置经验值（05 讲） 压测指标体系（06 讲） sysbench 压测实战（07 讲） 压测中观察机器负载（08 讲） 配置选定后 指标决定怎么压 压测同时盯硬件 Java 应用系统：2核4G / 4核8G 每秒抗几百请求（100 ~ 800 · 取决于单请求耗时） 数据库起步：8核16G 每秒抗 1000 ~ 2000 请求 · 再高 CPU/IO/内存负载就危险 数据库推荐：16核32G 每秒抗 2000 ~ 4000 请求 · 上万则可能被压垮 瓶颈在磁盘 IO：建议搭配 SSD 固态硬盘 · 系统的主要压力其实都压在数据库上 QPS / TPS QPS=每秒请求数（≈SQL 数）· TPS=每秒事务提交/回滚数 磁盘三大指标 IOPS 随机IO能力 · 吞吐量 MB/s · latency 写延迟 机器负载指标 CPU 负载 · 网络带宽（打满即到顶）· 内存使用率 压测原则 数据库压测 ≠ Java 系统压测 · 先压库，再压系统 一条命令造数 + 压测 prepare：20 张测试表 × 100 万行 · 10 线程 · 300 秒 run 模式：oltp_read_write / read_only / delete update_index / update_non_index / insert / write_only cleanup 清理测试数据 压测报告怎么读 thds 线程数 · tps 每秒事务数 · qps（读/写/其他拆分） lat (ms, 95%)：95% 请求延迟 · err/s · reconn/s 总报告：总请求数 / 事务数 · 平均与最大延迟 机器不同差异很大：TPS 几十到上千都可能 标准姿势：装 sysbench → prepare 造数 → run 压测（逐步增加线程数）→ 观察指标 → cleanup 清理 目的：测出这台机器上的数据库在硬件不出问题时的最大 QPS / TPS —— 心里有数 CPU · top 命令 load average 1/5/15 分钟 4 核 CPU：负载 4 = 全满 接近 3.5~4 就该停止加压 内存 · top 命令 Mem 行：total / used / free 80% 以内可接受 70%~80% 开始危险 磁盘 IO · dstat -d / -r 吞吐量：每秒读写字节数 IOPS：每秒随机读写次数 随机读写两三百次/秒是极限 网络 · dstat -n 网卡每秒收发流量 千兆网卡约 100MB/s 打满则 QPS 再也上不去 极限 QPS 的定义：硬件负载合理的范围内，把 QPS 提到最大 —— 而不是盲目加线程把机器压挂 图例 配置 / 经验值 指标体系 压测工具与方法 负载警戒线 原则 / 结论

机器配置经验值速查

  • • Java 系统 2核4G / 4核8G：每秒几百请求
  • • 数据库最低 8核16G：每秒 1000~2000 请求
  • • 数据库推荐 16核32G：每秒 2000~4000 请求
  • • 数据库务必上 SSD：瓶颈在磁盘 IO
  • • DBA 用调优参数模板部署 + 调 OS 内核参数

QPS vs TPS 一句话分清

  • • QPS：每秒处理多少请求（≈多少条 SQL）
  • • TPS：每秒多少事务提交或回滚
  • • 单个服务的并发 = QPS；交易系统每秒完成笔数 = TPS
  • • 压测工具：sysbench（造数 + 模拟并发 + 出报告）

压测的"安全边界"意识

  • • 边加线程边看 top / dstat，别盲压
  • • CPU load 接近核数、内存 80%、网卡打满就停
  • • 盲目压出的极限 QPS 在生产毫无意义
  • • 正确目标：硬件合理负载内的最大 QPS / TPS

③ 生产环境规划与压测 · MySQL 架构与生产实践知识图谱 · 依据第 05 ~ 08 讲整理