PHP数据库压测核心是模拟真实业务负载以暴露慢查询、连接池不足等瓶颈，需可控可复现、有指标能归因；须明确目标场景与数据规模，用真实逻辑生成流量，分层监控PHP/MySQL/系统指标，闭环验证优化效果，并确保环境隔离。
PHP 应用的数据库性能压测，核心是模拟真实业务负载，暴露瓶颈点（如慢查询、连接池不足、索引缺失、锁竞争），而非单纯刷高 QPS。关键在于“可控、可复现、有指标、能归因”。
明确压测目标与场景
不设目标的压测等于无效操作。需先定义：
- 业务目标：支撑 5000 并发用户下单？峰值每秒 800 次商品查询？事务成功率 ≥99.9%？
- 典型场景：读多写少（列表页+详情页）、写密集（秒杀扣减库存）、混合事务（支付闭环：查余额→扣款→记流水→发通知）
- 数据规模：使用与生产等比例的数据量（如用户表 500 万行，订单表 2000 万行），避免小数据集掩盖索引失效或磁盘 I/O 问题
构建贴近真实的压测流量
用真实请求逻辑替代简单 HTTP 轮询：
- 基于 PHP 脚本驱动：用 Guzzle 或 cURL 在 CLI 模式下发起请求，保留 session、token、参数签名等业务逻辑，避免被网关拦截或绕过鉴权层
- 参数动态化：用户 ID、商品 ID 等从预生成的 ID 列表中随机/轮询选取，避免缓存穿透或单条 SQL 占满连接
- 节奏控制：使用 ramp-up（如 5 分钟内从 0 增至目标并发），观察系统热身过程；穿插 think-time（用户思考时间）和 pacing（固定 TPS 间隔），更接近真实行为
监控必须覆盖三层：应用、数据库、系统
只看 Apache 或 MySQL 的平均响应时间会掩盖长尾问题：
立即学习“PHP免费学习笔记（深入）”；
- PHP 层：启用 XHProf / Blackfire / phpspy 抓取火焰图，定位 ORM 构建耗时、循环查库、未复用 PDO 连接等
- MySQL 层：开启 slow_query_log（long_query_time ≤ 0.1s），配合 pt-query-digest 分析；实时关注 Threads_running、Innodb_row_lock_waits、Handler_read_rnd_next（全表扫描回表）等状态变量
- 系统层：监控 CPU softirq（网络中断）、wait I/O、swap 使用、连接数（netstat -an | grep :3306 | wc -l），确认是否卡在 OS 或硬件
验证优化效果要闭环
每次调优后必须重跑相同压测脚本，对比关键指标：
- 核心指标：P95 响应时间下降幅度、错误率（5xx/超时）是否归零、TPS 是否达标、MySQL 的 Queries/sec 与 Questions/sec 差值（反映非查询语句占比）
- 归因验证：比如加了联合索引后，explain 显示 type=ref 且 rows 减少 90%，同时 slow log 中该 SQL 消失 → 可确认有效
- 防倒退机制：将压测脚本和基线结果纳入 CI 流程，新代码合并前自动触发轻量压测，防止性能劣化
不复杂但容易忽略：压测环境必须隔离（独立 DB 实例、禁用查询缓存、关闭慢日志采样率限制），否则数据污染或指标失真会让结论完全错误。
