性能调优

一、现象：加线程那一刻，监控曲线先升后崩 先给结论：对一个下游是数据库的 IO 型服务，把 Tomcat/业务线程池从 200 直接拉到 2000，QPS 几乎没涨（1200 → 1240），但 P99 从 180ms 一路飙到 950ms

一、现象与背景 先给结论：这次毛刺的根因不是代码、不是网络、不是 Redis 集群配置，而是一个业务同事顺手写的"全量拉取榜单"接口——它背后是一个 48MB 的 ZSet 大 Key。 具体场景：我们是做直播打赏榜单的，Redis Clu

背景：MySQL 8.0.36，InnoDB，一张订单表 order 约 1.2 亿行，主键 id，二级索引 idx_status (status)、idx_status_create (status, create_time)。列表页按

背景 上个月帮一个团队做容量评审，他们网关层给一个订单查询接口配了 QPS 限流 5000，压测跑下来 QPS 4800、P99 稳定 45ms，一切"正常"。结果上线第三天，下游 MySQL 主从切换，P99 飙到 2.3s，QPS 只跌

现象或背景 上个月给订单主表 "t_order"（2.4 亿行、单表 118GB，InnoDB，MySQL 8.0.32）补一个二级索引 "idx_status_create_time"，业务侧只给了一个 20 分钟的变更窗口，且要求全程不

背景 社区里已经有一篇讲「慢查询治理三件套顺序」的文章，把「先定位 → 再判断 → 最后加索引/改写」讲得很清楚，我基本认同。但真正到动手那一刻，我发现团队里吵得最凶的其实不是「顺序」，而是同一类慢查询，到底用哪条路去解：加索引、改写 SQ

【背景】 我负责一条 Flink 实时数据管道：Kafka → Flink（窗口聚合）→ JDBC Sink 批量写入 MySQL 8.0（InnoDB，binlog_format=ROW，sync_binlog=1）。QPS 约 3000

结论先行 先给结论：订单列表接口 P99 从 340ms 压到 52ms，靠的不是加机器，而是把 "filesort" 从"磁盘临时表"拉回"内存排序"。两个关键旋钮是 "sort_buffer_size" 和 "priority_sort

结论先行 P50 稳定、P99 间歇性飙 3 倍以上，CPU 不高、慢日志干净、连接池没打满——如果这几个条件同时满足，第一嫌疑不是数据库，是 GC。我 3 年里被「GC 毛刺」坑过两次，两次都是 G1 在 4G 堆上做的 Mixed GC

结论先行：连接池大小调成 CPU 核数的 10 倍、甚至 50 倍，往往不是变快，而是把抖动放大。下面是一次真实的 P99 抖动排查记录。 【现象】 一个订单查询接口，QPS 稳定在 800 左右，P50 一直 12ms，但 P99 间歇性