标签频道
写放大
该标签下的文章、提问与讨论帖。
【背景】 在处理 40 列宽表（行宽 ~1.5KB）+ 800 写 QPS 的场景中，我们经常面临一个关键决策：是否启用覆盖索引来避免回表，还是接受写放大带来的性能损失。这个决策直接影响到系统的吞吐量、延迟和资源利用率。 【常见分歧】 1.
背景 一张 40 列的宽表，行宽约 1.5KB，单表约 42GB，现有 5 个二级索引。写入画像：INSERT ~600 QPS + 状态 UPDATE ~200 QPS。 现象 一条高频查询（对账明细列表，~300 QPS）： SELEC
背景 我负责一套商户结算系统（MySQL 8.0.32 / InnoDB，单主 16C64G，buffer_pool 32G）。核心表 "t_trade_detail" 约 2800 万行，40 列宽表（大量 VARCHAR(128) 的业
背景：MySQL 8.0.36，InnoDB，16C64G 单机，innodb_buffer_pool_size=48G，innodb_change_buffering=all（默认）。核心表 t_order 约 4500 万行、含 8 个
先说结论：我见过绝大多数团队的索引数量是"长"出来的，不是"算"出来的。加的时候有理由，减的时候没流程。而写放大的代价是隐性的、持续的、累积的——你永远不会收到一条"你的第 7 个二级索引今天又让 INSERT 慢了 0.3ms"的告警，但
【背景】 去年接手一张 5200 万行的订单主表（MySQL 8.0.36，InnoDB，16C64G 单机），接手时已经挂了 11 个二级索引。业务方最痛的一条慢查询：按「商户号 + 下单时间范围 + 状态」做分页查询，没走索引时 P99
«结论先行：高频 UPDATE 低选择性列时，真正的瓶颈不是 CPU、不是主键索引，而是「二级索引 B+ 树的随机 I/O + 页分裂」，而 InnoDB 用来吸收这类成本的机制叫 change buffer，它的命中率直接决定你的 P99
«结论先行：RocksDB 的写毛刺，90% 不是「写慢」，而是「写被自己人卡住了」——前台写路径本身（memtable 追加 + WAL 落盘）在 NVMe 上稳定 1~3ms，真正让 P99 飙到 200ms 的，是后台 compact
一、现象：没人报警，但 INSERT 吞吐悄悄掉了 40% 背景：一套 MySQL 8.0.32 / InnoDB 的物流履约系统，核心表 "t_fulfillment_item"（履约明细），规模 4500 万行、单表数据 28.6GB、
文
标题
摘要