qps上不去的主因是mysql配置与硬件协同失衡。具体包括：innodb日志文件过小引发频繁checkpoint、max_connections与超时参数不匹配导致连接堆积、innodb_flush_log_at_trx_commit=1加剧i/o瓶颈、table_open_cache不足触发高频文件操作、缺失索引使全表扫描逃逸慢日志，以及pt-query-digest未聚类预编译语句致分析失真。
用 sysbench 做基础压测时，为什么 QPS 上不去？
不是并发数设高就一定压得起来，sysbench 默认的 --threads=16 在多数测试机上反而会因锁争用拖慢整体吞吐。真实瓶颈常藏在 MySQL 的连接池、日志刷盘和临时表配置里。
-
innodb_log_file_size太小（如默认 48MB）会导致频繁 checkpoint，压测中Innodb_log_waits明显上升，QPS 波动剧烈 -
max_connections不够时，sysbench报错Too many connections，但实际连接数可能远低于该值——因为wait_timeout和连接复用策略影响了连接回收速度 - 没关
innodb_flush_log_at_trx_commit=2就跑写密集型压测，磁盘 I/O 成死结，iostat -x 1里%util长期 100%，await拉到 20ms+ 是典型信号
查 SHOW PROCESSLIST 看到大量 Sleep 状态，是应用层问题还是 MySQL 配置问题？
不能直接归咎于应用。MySQL 中 Sleep 状态本质是连接空闲，但持续堆积说明连接没被及时释放或复用策略失当。重点盯三个地方：
-
wait_timeout和interactive_timeout设太高（比如 28800 秒），导致连接长期挂起却不释放，Threads_connected慢慢涨满max_connections - 应用用了长连接但没做连接健康检查，中间网络抖动后连接卡在
Sleep，后续请求全排队等待 -
performance_schema开着但没开相关消费者（如events_statements_history_long），根本看不到这些 Sleep 连接上一次执行了什么语句，无法判断是否被慢查询拖住
slow_query_log 开了却没记录明显慢 SQL，瓶颈可能在哪？
慢日志只捕获单条语句执行时间超阈值的 SQL，但压测中的性能坍塌往往来自组合效应：锁等待、缓冲区不足、解析开销。这时候要切到更底层指标。
-
long_query_time设成 2 秒，但大量 800ms 的语句反复抢同一行锁，Innodb_row_lock_time_avg却飙到 150ms——这比单条慢 SQL 更伤吞吐 -
table_open_cache不足时，每秒Opened_tables持续上涨，说明 MySQL 在反复打开/关闭 .frm 文件，CPU 花在文件系统路径解析而非执行 SQL - 没开
log_queries_not_using_indexes，而压测表又缺关键索引，结果全是全表扫描，但每条都不到long_query_time阈值，慢日志一片空白
用 pt-query-digest 分析慢日志，为什么 top 语句和监控看到的热点不一致？
pt-query-digest 默认按响应时间排序，但压测中真正卡住系统的，往往是高频率低耗时语句引发的锁竞争或 CPU 解析压力。它不会自动合并带不同参数的预编译语句，容易把同一类查询拆成几十条“不同”SQL。
- 加
--filter '$event->{fingerprint} =~ m/^SELECT.*FROM orders/i'手动聚类业务主表访问，比默认输出更有指向性 - 别只看
Count或Query_time，重点关注Lock_time和Rows_examined的比值——若Rows_examined是Rows_sent的百倍，说明索引失效或条件没走对 -
pt-query-digest --report-format json输出后，用jq提取.items[0].Query_time.avg和.items[0].Lock_time.avg对比，差值大意味着锁是主要延迟源，不是 SQL 本身慢
压测不是比谁跑出更高 QPS，而是让每个数字背后都有可解释的链路。最常漏掉的是硬件层反馈——比如 vmstat 1 里 si/so 非零说明内存交换已启动，这时再调 MySQL 参数都是隔靴搔痒。
