性能调优

«结论先行：RocksDB 的写毛刺，90% 不是「写慢」，而是「写被自己人卡住了」——前台写路径本身（memtable 追加 + WAL 落盘）在 NVMe 上稳定 1~3ms，真正让 P99 飙到 200ms 的，是后台 compact

背景 我负责一个核心查询服务：Spring Boot 3.2 + JDK 17.0.10（G1，"-Xmx4g -XX:MaxGCPauseMillis=50"）+ MySQL 8 + Redis 7，K8s 1.28.4 / contai

«结论先行：容器里 "pids.max" 撞墙，是一种没有「软阶段」、撞了直接拒绝 fork、且监控基本看不到的隐形杀手。CPU limit 会节流、memory limit 会 OOM，而 pids 撞墙时 CPU 和内存全绿、"dmes

背景 我负责一条实时 ETL 管道的核心组件：从 MySQL 读 50~200 万行增量数据做转换后写回目标库。JDK 17 + HikariCP 5.1，maxSize=20。触发方式是定时任务 + Kafka 事件双驱动，高峰期并发读连

«结论先行：InnoDB 的主键是聚簇索引的物理顺序，主键的随机性直接决定写入是顺序 IO 还是随机 IO。把 UUID v4 换成雪花 ID，同样的批量写入 P99 从 1.8s 降到 52ms，收益 35 倍——这不是"ID 格式"问题

背景 热榜上"连接池怎么调""超时重试怎么配""GC 怎么选"聊得很透，但我做了 3 年性能优化，发现一个更前置、却几乎没有团队形成共识的问题：线上 P99 劣化被报警抓到的那一刻，你做的第一个动作是什么？ 我至少见过三种截然不同的"第一反

«结论先行：软删除（"deleted_at" 列 + "WHERE deleted_at IS NULL"）用得越久，二级索引里「同一个 customer_id 下挂着一串已删除行」的簇就越大，优化器从「覆盖索引直接出结果」退化成「索引扫描

【背景】 我负责一个支付编排服务（JDK 17 + Spring Boot 3，单机 8C16G，前置 4 实例，K8s cpu limit=4），对外 QPS 峰值约 1.5k，P99 目标 500ms。一次请求内会并行发起 4 个下游

一、现象：一条"写入"接口，把磁盘 IO 打到 92% 先说结论：这次写入慢，不是慢 SQL、不是连接池、也不是网络，而是"主键用 UUID 导致 InnoDB 随机写 + 页分裂"。把主键换回自增后，同一台机器、同一份流量，写入 P99

结论先行 批量插入慢，十有八九不是 SQL 写得差，而是「一次只提交一条」+「驱动没把 batch 拼成 multi-row INSERT」+「每条都强制刷盘」三件事叠在一起。我们一个埋点落库服务，单机写入吞吐从 1200 行/s 提到 9

«结论先行："linger.ms" 不是「给消息加多少毫秒延迟」的旋钮，而是批次（RecordBatch）的等待窗口；真正决定一条消息何时上路的，是 batch 队列里 batch 的三种刷盘触发路径——批满、超时、"flush()" 显式

背景 我带了 15 年后端，一半时间在做高并发链路。最近帮一个团队做容量评审，他们面对一个下单接口 P99 从 80ms 抖到 1.2s 的问题，给出的方案是"把下单同步流程拆成消息队列异步化，前端改成轮询结果"。我当场泼了冷水：你这不是把

«结论先行：「按 uid 尾号分桶灰度」本身没错，错的是把灰度桶当成「随机抽样」去读指标。尾号分桶在真实业务里几乎必然是非随机的——老用户、高活用户、特定地区/机型用户的 uid 分布高度集中在某些尾号段，导致 5% 灰度桶里装的根本不是「

背景 做了 10 年大数据平台，最近半年在两个团队里反复撞到一个"分完之后才暴露"的坑：分库分表把单表 80GB 拆到了 16 个分片，单片查询 P99 从 120ms 降到 8ms，看起来很完美；结果第二天报表团队来找——"用户维度的 G

【背景】 我负责一个多租户 SaaS 的数据分析查询服务：JDK 17 + Spring Boot 3 + PostgreSQL 15（单主库，16C64G）+ PgBouncer（transaction 模式，pool_size=20/租

背景 MySQL 8.0.30，InnoDB，一台 64C / 256G 裸金属，承载 3 个业务库。核心库有一张 1.2 亿行的支付流水表 "t_pay_flow"（PK=id，二级索引 "idx_merchant_status"、"id

结论先行 JDK 8u131 及更早版本（x86 + Linux epoll）存在一个 Selector 空轮询 bug（JDK-6670342）："Selector.select()" 在没有事件时仍立即返回，导致 "select → 判

«结论先行：gRPC 的 server-streaming 接口，OOM 和 goroutine 泄漏的根因几乎都不是"发不出去"，而是"服务端在内存里预生成了全量数据"，以及"客户端取消后服务端 goroutine 没感知到、继续空跑"。

背景 我在一个 24 节点的 K8s 1.28 集群上跑一套 Go 1.21 的实时行情计算服务，节点规格是双路 32C（Intel 8358，2 个 NUMA node，每个 16C）/128G/512G NVMe，containerd

一、现象：写入 QPS 没变，P99 却从 6ms 飙到 11ms 去年 Q3 给一套支付清结算系统做性能治理。核心表 "t_settle_record"： - 规模：单表 2.8 亿行、InnoDB 16KB 页、MySQL 8.0.32