MySQL

一、现象与背景 先给结论：这次毛刺的根因既不是 InnoDB、不是 binlog、不是网络，而是 Linux 内核的 page cache 回写策略——"vm.dirty_ratio" 默认 20% 在 32GB 内存的机器上等于允许 6.

背景：MySQL 8.0.36，InnoDB，订单流水表 t_settlement 约 1.2 亿行，PK=id，现有 3 个二级索引（idx_merchant_time、idx_status、idx_batch_no）。业务要求新增复合索

一、现象：没人报警，但 INSERT 吞吐悄悄掉了 40% 背景：一套 MySQL 8.0.32 / InnoDB 的物流履约系统，核心表 "t_fulfillment_item"（履约明细），规模 4500 万行、单表数据 28.6GB、

结论先行：读写分离里「我刚写完，读从库却是旧值」，根因不是代码 bug，而是主从复制是异步的——主库把 binlog 落盘就返回成功，从库要等 relay log 拉取 + 重放，中间这段窗口（毫秒到秒级）读从库必然读到旧数据。解法分两层：

背景：MySQL 8.0.36，InnoDB，REPEATABLE READ。一张 3200 万行的工单表 tickets，主键 id（自增），二级索引 idx_tenant_status (tenant_id, status, creat

一、现象：监控里那条「不致命」的曲线 先给背景。一套 MySQL 8.0.32 / InnoDB 的订单+账务系统，主库 "innodb_buffer_pool_size=32GB"、"innodb_purge_threads=4"、"in

背景 做大数据平台这几年，我遇到的最频繁的架构讨论不是「怎么加索引」，而是「表越来越大，历史数据怎么办」。 一个很典型的场景：订单流水表从 2000 万涨到 1.2 亿行，单表 80GB+，80% 的数据是 3 个月以前的。日常业务查询 9

背景：MySQL 8.0.36，单主 + 2 从（半同步 rpl_semi_sync_master_wait_for_slave=ON），主库 32C/128G/ESSD PL2，从库同规格但磁盘是 SSD。binlog 日均增长约 200

背景：MySQL 8.0.34，InnoDB，业务库有一张订单流水表 t_order_flow（约 1.2 亿行，PK=id，二级索引 idx_merchant_time (merchant_id, created_at)、idx_stat

一、现象与背景 去年双11前压测，我们一个订单服务（Spring Boot 3.2，JDK 21，HikariCP 5.1.0，单实例 8C16G，前置 4 个实例）出现诡异故障：压测到 1200 QPS 时，大量请求在 30s 后超时，日

«结论先行：索引没变、SQL 没变、buffer pool 命中率也没掉，但 P99 还是从 15ms 飙到了 3.4s——根因是 InnoDB 的统计信息（cardinality）在数据批量写入后严重失真，优化器据此选错了索引/访问路径。

MySQL 连接池打满不是 max_connections 的锅：一次 P99 从 80ms 飙到 12s 的复盘 一、现象与背景 2024 年 3 月，某中型电商订单服务在内部压测中出现了严重的性能退化： - 数据库：MySQL 8.0.

一、现象与背景：连接数翻倍，接口反而更慢 先给结论：当瓶颈在 InnoDB 行锁排队时，把连接数加上去，QPS 会微涨、P99 会暴涨，因为新连接只是多排队的人，不是多干活的人。 具体场景：一个库存扣减服务，MySQL 8.0.32（16C

背景：订单表 t_order 约 4200 万行，InnoDB，MySQL 8.0.32，已建联合索引 idx_ab (a, b)，其中 a 是商户ID（高基数，单值查询命中 200~3000 行不等），b 是创建时间（datetime）。

一、现象：一次机房断电，订单表少了 412 条 去年 11 月，一家电商客户机房突然断电（UPS 顶了 90 秒，但一台主机因内存吃紧提前 OOM 重启）。恢复后业务方发现：断电前 1 分钟内的下单里有 412 条「客户端收到 200、但订

背景 做了 5 年大数据平台，我见过太多团队在"要不要把半结构化数据塞进 JSON 字段"这件事上反复横跳。尤其是 MySQL 5.7+ 有了原生 JSON 类型、PostgreSQL 有 JSONB + GIN 索引之后，这个选项从"忍一

背景：我在维护一个订单中台，入口 QPS 约 1500，单次请求平均要串行调用 2~3 个下游（库存服务、价格服务、风控服务），其中价格服务最终会落到 MySQL 做聚合查询。整体链路我做了三层超时：Tomcat/网关 800ms → Sp

背景：MySQL 8.0.32 / InnoDB，一张约 1.8 亿的链路追踪明细表 trace_detail，字段：id (bigint 自增 PK)、trace_id (varchar(32))、span_name (varchar(6

«结论先行：在 InnoDB 里，往带唯一索引的表并发 INSERT，最常见的死锁根因不是「写写竞争」，而是 Duplicate Key 检查触发的 S 锁 + 间隙锁，叠加自增主键的插入顺序不一致，形成 AB-BA 环路。这个坑我踩了两次

背景 社区里已经有一篇《超时与重试：高并发后端最容易翻车、却最少被认真讨论的两件事》把「超时不是运维项」讲得很透了，我基本认同。但最近带团队治理一批慢查询时，我发现一个被绕过去的问题：应用侧的超时（HikariCP "connectionT