📖 本篇简介：秒杀、双 11、大促零点开抢，数据库要在几秒内承受平时几十上百倍的流量。这不是单靠"加机器"能解决的，而是一整套"限流 + 缓存 + 削峰 + 分库分表 + 降级"的组合拳。本篇用 10 个真实大促场景，带你从库存扣减、热点行、读写分离、主库保护、容量压测、连接数、缓存一致性、跨分片、故障预案到战后对账，走一遍完整的大促数据库备战。示例基于 MySQL 8.0，学完你能系统回答"大促数据库怎么扛"这类架构题。
目录
- 1 本篇导读与大促数据库挑战全景
- 2 场景一：秒杀瞬时高并发如何扛住库存扣减
- 3 场景二：热点商品行更新打串行如何优化
- 4 场景三：大促读多写少如何做读写分离
- 5 场景四：大促期间如何保护主库不被打挂
- 6 场景五：大促前如何做容量评估与压测
- 7 场景六：大促当天数据库连接数飙升怎么办
- 8 场景七：大促期间缓存与数据库一致性怎么保证
- 9 场景八：分库分表后大促跨分片查询怎么办
- 10 场景九：大促故障预案与降级开关如何设计
- 11 场景十：大促后数据对账与容量回收
- 12 大促高并发方案速查表
- 13 常见坑与注意事项
- 14 练习题与自测
1 本篇导读与大促数据库挑战全景
大促对数据库的压力不是均匀的，而是"尖峰型"：零点那几分钟，QPS 可能是平时的 50 倍。设计原则只有一句话——让数据库尽量少干活、只干必须它干的活。
大促数据库方案的分层防线（从外到内）：
1. 接入层：限流、排队、验证码、答题，把无效流量挡在数据库前面；
2. 缓存层：热点数据全部进 Redis，读请求打不到数据库；
3. 削峰层：下单请求先进消息队列，异步落库，把瞬时洪峰拉平；
4. 数据库层：主库只扛写，从库扛读，热点行拆分，分库分表分散压力；
5. 降级层：非核心功能随时可关，保住交易主链路。
下面 10 个场景，就是这套防线的逐环拆解。
2 场景一：秒杀瞬时高并发如何扛住库存扣减
场景描述：一个秒杀商品 1000 件，零点瞬间涌来 10 万人同时下单。如果所有人都直接 UPDATE stock=stock-1，数据库瞬间被打挂，还会超卖。怎么设计？
考察点：考察库存扣减的正确性（不超卖）与并发性（不打挂库）的平衡。
解答思路：
核心是"先扣库存、再下单"，并且把扣库存这个动作从数据库的并发竞争里解放出来。
第一步，用 Redis 预扣库存，把 10 万次请求拦在缓存层：
-- 本示例基于 MySQL 8.0
-- 数据库侧最终的库存扣减，必须带"库存>0"条件防止超卖
UPDATE seckill_stock
SET stock = stock - 1
WHERE sku_id = 1001 AND stock > 0; -- 关键：stock>0 作为乐观条件
-- 影响行数 = 1 说明扣减成功；= 0 说明库存已空，直接返回售罄
第二步，成功扣库存的请求，把下单消息丢进 MQ，异步生成订单，把数据库写入削峰：
# 本示例为示意：Redis 预扣库存 + 发 MQ 异步下单（无真实服务，仅讲流程）
# 1. Redis DECR 原子扣减，负数说明没抢到
# remain = redis.decr("seckill:stock:1001")
# if remain < 0:
# redis.incr("seckill:stock:1001") # 回弹
# return "售罄"
# 2. 抢到额度，发消息异步落订单
# mq.send({"sku_id":1001, "user_id":uid})
# 3. 用户端先返回"排队中"，轮询结果页
这样数据库只需要慢慢消费 MQ 里的订单，写入压力被拉平成一条平缓曲线，而不是零点的一根针。
还要补一个关键设计：库存扣减要幂等。用户可能重复点击、MQ 可能重投，同一个用户对同一个商品的请求扣两次库存就错了。工程上用"用户+商品"做唯一约束或去重表，保证一个用户对一个秒杀商品只能抢到一次额度。
-- 本示例基于 MySQL 8.0
-- 去重表：一个用户对一个秒杀商品只能成功一次
CREATE TABLE seckill_record (
sku_id BIGINT NOT NULL,
user_id BIGINT NOT NULL,
PRIMARY KEY (sku_id, user_id) -- 联合唯一键，重复插入直接报错
);
-- 插入成功才算抢到；重复插入会撞唯一键，被拦截
INSERT IGNORE INTO seckill_record(sku_id, user_id) VALUES(1001, 666);
追问：Redis 扣了库存但 MQ 消息丢了，导致 Redis 少了、数据库没扣，库存对不上怎么办？
这就是经典的缓存与数据库不一致问题，要靠"最终一致对账"兜底：大促后定时比对 Redis 库存和 DB 库存，差异修复。
3 场景二：热点商品行更新打串行如何优化
场景描述：秒杀商品的库存都存在同一行（sku_id=1001），几万个更新都要锁这一行，InnoDB 行锁把并发压成了串行，这一行成了热点。怎么破？
考察点：考察热点行（hot row）问题的解决思路。
解答思路：
热点行的本质是"所有更新挤同一把锁"。解法是把一行拆成多行，分散锁竞争：
-- 本示例基于 MySQL 8.0
-- 拆库存：把 1000 件库存拆到 10 个分片行，每行 100 件
-- sku_id=1001_0 ~ 1001_9，各自独立加锁，并发度提升 10 倍
CREATE TABLE seckill_stock_shard (
sku_id BIGINT NOT NULL, -- 拆片后带后缀，如 1001_0
stock INT NOT NULL,
PRIMARY KEY (sku_id)
);
-- 扣减时随机选一个分片行
UPDATE seckill_stock_shard
SET stock = stock - 1
WHERE sku_id = CONCAT(1001, '_', FLOOR(RAND()*10)) -- 随机落到 0~9 分片
AND stock > 0;
-- 如果该分片扣减失败（库存为0），换下一个分片重试
另一种思路是库存全放 Redis，数据库只做最终对账，彻底避开数据库行锁竞争。秒杀场景一般以 Redis 为主，DB 只做异步落地和兜底。
追问：拆成分片库存后，怎么避免某个分片扣光、别的分片还有货？
随机分片能基本均匀分布；个别分片先空时，前端扣减逻辑做"分片库存为 0 就换下一个分片"的重试即可。
4 场景三：大促读多写少如何做读写分离
场景描述：大促期间商品详情、库存查询、订单列表都是读请求，占了 95% 的流量，但主库既要扛写又要扛读，快顶不住了。怎么用读写分离给主库减压？
考察点：考察主从架构下读写分离的路由策略。
解答思路：
读写分离的核心是"写走主库、读走从库"，由中间件（ProxySQL、ShardingSphere）或代码层路由：
-- 本示例基于 MySQL 8.0
-- 主库（写入）：处理 INSERT/UPDATE/DELETE
-- 从库（读取）：处理 SELECT
-- 路由规则：
-- 事务内的读（要读到刚写的数据）→ 强制走主库
-- 普通只读查询 → 走从库
关键坑是主从延迟：刚写完的数据立刻去从库读，可能读不到。所以要分两类读：
- 必须读最新的（比如"我的订单"刚下单后刷新）→ 走主库或走"读己之写"策略；
- 容忍短暂延迟的（商品详情、列表）→ 放心走从库。
-- 本示例基于 MySQL 8.0
-- 监控主从延迟，延迟超过阈值时把读流量切回主库保护一致性
SHOW SLAVE STATUS\G
-- 看 Seconds_Behind_Master 列：从库落后主库多少秒
-- 这个值 > 1s 就要警惕，> 5s 建议把关键读切主库
追问：读写分离下，"我刚下单的订单列表里没有"怎么解？
这是主从延迟导致的读不一致。方案：下单后的短时间窗口内，强制"读己之写"走主库；或引入 GTID 等待，等从库追上指定位点再读。
5 场景四：大促期间如何保护主库不被打挂
场景描述：大促当天，有运营同事直接在主库跑了一个大报表查询，几分钟内主库 CPU 飙升，交易开始超时。怎么从架构上保护主库？
考察点：考察主库保护意识——主库只做交易写入，分析/报表流量必须隔离。
解答思路：
第一原则：主库是命根子，一切非交易流量都不该打主库。
-- 本示例基于 MySQL 8.0
-- 1. 权限隔离：业务账号和报表账号分开，报表账号禁止连主库
-- 2. 资源组（8.0 RESOURCE GROUP）：把报表会话绑到低优先级资源组
CREATE RESOURCE GROUP report_group TYPE=USER VCPU=0-1 THREAD_PRIORITY=5;
-- 3. 语句超时：给非核心会话设置最大执行时间，防止大查询拖垮库
SET SESSION max_execution_time = 30000; -- 30 秒后自动 kill 这条 SELECT
第二，大报表、复杂查询强制走独立的从库或 OLAP 系统（如 ClickHouse），不要和交易抢资源。第三，大促期间关闭一切非必要的定时任务、备份任务，把 IO 留给交易。
-- 本示例基于 MySQL 8.0
-- 紧急时设置全局语句超时，拦住失控的大查询（毫秒）
SET GLOBAL max_execution_time = 10000; -- 所有 SELECT 超 10 秒自动中止
追问：max_execution_time 对所有语句都生效吗？
只对 SELECT 生效，且不限制存储过程里的语句；它是"软超时"，对 UPDATE/DELETE 不起作用，写操作要靠事务超时和 KILL。
大促前的主库保护清单，建议逐项打勾：
| 保护动作 | 命令/手段 | 作用 |
|---|---|---|
| 报表流量隔离 | 报表账号只许连从库/OLAP | 防止大查询占主库 |
| 语句超时 | SET GLOBAL max_execution_time | 自动杀失控 SELECT |
| 关闭定时任务 | 停备份、停统计 job | 让出 IO 给交易 |
| 资源组隔离 | RESOURCE GROUP | 低优先级任务限流 |
| 慢日志阈值调低 | long_query_time=0.5 | 提前发现新慢 SQL |
6 场景五：大促前如何做容量评估与压测
场景描述：大促还有两周，你作为 DBA 怎么评估现有数据库能不能扛住预计流量？提前要做哪些准备？
考察点：考察容量规划和压测方法论，这是架构师的基本功。
解答思路：
容量评估三步：
第一步，算流量：预估峰值 QPS = 平时 QPS × 峰值倍数，读写拆开算。第二步，算单库上限：用历史压测数据估算单主库能扛多少写 TPS、多少读 QPS。第三步，算缺口：预估峰值 ÷ 单库上限 = 需要的库数量，留 30% 余量。
-- 本示例基于 MySQL 8.0
-- 压测前先看当前库的基线能力
SHOW GLOBAL STATUS LIKE 'Questions'; -- 总请求数
SHOW GLOBAL STATUS LIKE 'Innodb_rows_updated'; -- 写行数
SHOW ENGINE INNODB STATUS; -- 看 buffer pool 命中率、行锁等待
压测要用 sysbench 或业务回放，在准生产环境把流量放大到预估峰值的 1.5~2 倍，找出拐点（CPU/IO/连接哪个先到顶）：
# sysbench 压测写能力（示例命令，本环境无 MySQL 服务，仅作说明）
sysbench oltp_write_only --mysql-host=127.0.0.1 --threads=64 --time=120 run
# 观察：TPS、QPS、CPU 利用率、延迟 P99，找到性能拐点
追问：压测时数据量要和生产一致吗？
必须一致，或者接近。用空库压出来的数字毫无意义，因为执行计划、buffer pool 命中、索引效率都依赖真实数据规模。
压测还有两个容易被忽略的点：一是预热，压测前要先跑一轮让数据进入 buffer pool，否则冷启动数据全读磁盘，数字偏低；二是看长尾延迟，不能只看平均 TPS，要盯 P99/P999，大促时真正拖垮体验的是那 1% 的慢请求。压测报告至少要包含下面这张表：
| 压测指标 | 健康参考值 | 告警线 |
|---|---|---|
| CPU 利用率 | < 70% | > 85% 持续 1 分钟 |
| buffer pool 命中率 | > 99% | < 98% |
| TPS | 预估峰值的 60% 以内 | 接近压测拐点 |
| P99 延迟 | < 200ms | > 500ms |
| 主从延迟 | < 1s | > 5s |
7 场景六：大促当天数据库连接数飙升怎么办
场景描述：大促零点，应用服务器疯狂新建数据库连接，Threads_connected 逼近 max_connections 上限，新请求拿不到连接直接报错。怎么处理？
考察点：考察连接池与连接数治理。
解答思路：
先理解一个误区：连接越多越快是错的。MySQL 每个连接都要占内存，连接数超过 CPU 核数很多倍后，上下文切换反而让吞吐下降。大促要做的是"控制连接数"而不是"放大连接数"。
-- 本示例基于 MySQL 8.0
-- 1. 看当前连接数和上限
SHOW VARIABLES LIKE 'max_connections'; -- 上限
SHOW GLOBAL STATUS LIKE 'Threads_connected'; -- 当前
SHOW GLOBAL STATUS LIKE 'Threads_running'; -- 真正在跑的（关键指标）
-- 2. 关键认知：Threads_running 才是并发瓶颈，不是 Threads_connected
-- 大量 Sleep 连接占着名额不干活，要清理
应用侧用连接池（如 HikariCP）统一管理，池大小设为"CPU 核数 × 2 + 有效磁盘数"附近，而不是无限开。清理闲置连接：
-- 本示例基于 MySQL 8.0
-- 设置连接空闲超时，让 Sleep 连接自动回收
SET GLOBAL wait_timeout = 60; -- 空闲 60 秒后断开
SET GLOBAL interactive_timeout = 60;
追问：为什么大促时连接池要调小而不是调大？
因为数据库的处理能力有限，让 100 个请求排队竞争 16 个工作线程，比开 100 个连接互相踩踏更快。连接池过大反而会把数据库压垮。
这里顺带把连接相关的几个参数理清，面试常混：
| 参数 | 含义 | 大促建议 |
|---|---|---|
| max_connections | 数据库最大连接数上限 | 按内存评估，不是越大越好 |
| Threads_connected | 当前已建立连接数 | 盯它逼近上限就要告警 |
| Threads_running | 当前真正在执行的并发数 | 这才是真正的并发压力 |
| wait_timeout | 空闲连接多久后断开 | 调小（如 60s）及时回收 Sleep |
| 连接池大小 | 应用侧池上限 | 按库数分摊，总和别超 max_connections |
一个常见错误：每个应用实例都开 500 连接，几十个实例加起来上万连接，瞬间把 max_connections 打爆。正确做法是"所有实例连接池总和 < max_connections 的 80%"。
8 场景七：大促期间缓存与数据库一致性怎么保证
场景描述：商品价格、库存都缓存在 Redis，大促期间频繁更新，怎么保证缓存和数据库不出现严重不一致？
考察点：考察缓存更新策略与一致性方案。
解答思路：
大促场景最常用的是Cache Aside（旁路缓存）模式：
读：先读缓存 → 命中就返回 → 未命中读数据库 → 回填缓存
写：先更数据库 → 再删除缓存（不是更新缓存）
为什么是"删除缓存"而不是"更新缓存"？因为并发更新时，直接更新缓存容易产生脏数据；删除缓存让下次读时重新从 DB 加载，更安全。
-- 本示例基于 MySQL 8.0
-- 写流程（伪代码）：
-- 1. UPDATE goods SET price=? WHERE id=? -- 先更库
-- 2. DEL Redis "goods:price:1001" -- 再删缓存
-- 为什么删而不是更？避免并发下两个写请求把缓存写乱
极端情况（先更库成功、删缓存失败）会短暂不一致，大促期间可以用"延迟双删"或"订阅 binlog 异步删缓存"（Canal）兜底。
追问：缓存击穿（热点 key 过期瞬间大量请求打 DB）大促怎么防？
热点 key 永不过期 + 后台异步刷新；或用互斥锁，只让一个请求回源 DB，其他等结果。
9 场景八：分库分表后大促跨分片查询怎么办
场景描述：订单表已经按 user_id 分成了 64 个分片。大促当天运营要"查昨天全平台所有订单做实时大屏"，这是跨全分片查询，怎么搞？
考察点：考察分库分表后的查询限制与应对——跨分片聚合是分库分表最大的痛点。
解答思路：
分库分表后，跨分片的聚合、排序、分页、count 都变得昂贵。应对思路：
1. 大屏/报表不查业务库：把数据通过 binlog 同步到 OLAP（ClickHouse/ES），大屏查分析库，不碰交易库；
2. 禁止不带分片键的查询：订单查询必须带 user_id，避免路由到所有分片；
3. 全局聚合用中间件归并：ShardingSphere 能做跨分片 count/sum，但代价是把各分片结果拉到内存聚合，量大时很慢。
-- 本示例基于 MySQL 8.0（分片后示意）
-- 正确：带分片键 user_id，只路由到 1 个分片，效率高
SELECT * FROM orders WHERE user_id = 12345 AND status = 2;
-- 错误：不带分片键，要广播到 64 个分片再归并，大促期间坚决禁止
SELECT COUNT(*) FROM orders WHERE create_time >= '2026-10-07';
-- 这种分析需求应走 binlog 同步到的分析库，不查分片库
追问：跨分片的全局唯一 ID 怎么生成？
分库分表后自增主键会冲突，要用雪花算法（Snowflake）或号段模式生成全局唯一 ID。
雪花 ID 的思路是把"时间戳 + 机器号 + 序列号"拼成一个 64 位整数，既全局唯一又大致有序，适合做分片键和主键。号段模式则是每次从 DB 取一段 ID 缓存在本地，用完再取下一段，简单可靠。面试时能把这两种方案的优缺点（雪花依赖时钟、号段依赖 DB）讲清楚，就达到架构水平了。
| 全局 ID 方案 | 优点 | 缺点 |
|---|---|---|
| 雪花算法 Snowflake | 本地生成、无单点、趋势递增 | 依赖时钟回拨 |
| 号段模式 | 简单可靠、易理解 | 依赖号段 DB，要缓存一段 |
| UUID | 本地生成无依赖 | 无序，作主键索引性能差 |
10 场景九：大促故障预案与降级开关如何设计
场景描述：大促期间要保证核心交易链路万无一失，但次要功能（推荐、评价、营销）出问题不能拖累主流程。怎么设计降级开关？
考察点：考察高可用架构里的"降级"思维——保核心、舍边缘。
解答思路：
降级的本质是"按重要性排队，资源不够时先砍最不重要的"。把功能分级：
| 级别 | 功能 | 故障时动作 |
|---|---|---|
| P0 核心 | 下单、支付、扣库存 | 绝不降级，全力保 |
| P1 重要 | 订单查询、购物车 | 可短暂限流 |
| P2 次要 | 推荐、评价、营销弹窗 | 一键关闭 |
| P3 边缘 | 埋点、日志、个性化 | 直接停 |
# 本示例为示意：一个基于配置中心的降级开关判断（无真实配置中心，仅讲逻辑）
# def can_show_recommend():
# # 从配置中心读开关，大促期间可随时远程关闭，无需发版
# return config.get("switch.recommend.enable", True)
# if not can_show_recommend():
# return "推荐已降级" # 直接返回兜底数据，不查库不调下游
关键是开关要远程可控、秒级生效，不能靠改代码发版。每个开关都要有"降级后返回什么兜底数据"，不能让页面空白报错。
追问：降级和限流有什么区别？
限流是"控制进来多少请求"，保护系统不被打垮；降级是"主动关掉哪些功能"，把资源让给核心链路。两者常配合使用。
11 场景十：大促后数据对账与容量回收
场景描述：大促平稳度过，零点洪峰过去了。但你知道大促期间因为削峰、异步、缓存，数据可能有不一致。战后要做什么？
考察点：考察大促收尾的运维闭环——对账、回收、复盘。
解答思路：
战后三件事：
1. 数据对账：比对 Redis 库存 vs DB 库存、MQ 消息 vs 订单表、支付流水 vs 订单状态，找出不一致并修复；
2. 容量回收：大促临时扩容的从库、临时加的缓存分片，评估是否缩容省钱；
3. 复盘：导出大促当天的 QPS、TPS、延迟、错误率曲线，找出哪里接近瓶颈，为下次大促做准备。
-- 本示例基于 MySQL 8.0
-- 对账示例：找出"扣了库存但没生成订单"的异常（异步链路丢消息）
SELECT s.sku_id, s.stock AS db_stock,
(SELECT COUNT(*) FROM orders o WHERE o.sku_id = s.sku_id) AS order_cnt
FROM seckill_stock s
HAVING db_stock < 0 OR order_cnt = 0; -- 找出库存与订单对不上的商品
# 本示例为 sqlite3 演示：模拟大促对账，找出支付单与订单状态不一致
import sqlite3
conn = sqlite3.connect(":memory:")
cur = conn.cursor()
cur.execute("CREATE TABLE orders(order_id INT, status TEXT, pay_status TEXT)")
cur.executemany("INSERT INTO orders VALUES(?,?,?)",
[(1,'PAID','PAID'), (2,'NEW','UNPAID'), (3,'PAID','UNPAID')]) # 3号单异常
conn.commit()
# 找出：订单状态已支付但支付状态未支付的异常单
for row in cur.execute("SELECT order_id FROM orders WHERE status='PAID' AND pay_status='UNPAID'"):
print("异常单:", row[0]) # 输出 异常单: 3
conn.close()
上面脚本实跑会输出 异常单: 3，正是那条状态不一致的订单。
追问：大促复盘最该看哪个指标来决定下次扩容？
看峰值时刻 P99 延迟和 CPU/IO 利用率。如果峰值时 CPU 已经持续 80% 以上，下次就要提前扩容；如果很闲，说明过度扩容了。
12 大促高并发方案速查表
| 问题 | 首选方案 | 备选/兜底 |
|---|---|---|
| 瞬时秒杀洪峰 | Redis 预扣库存 + MQ 削峰 | 本地限流、前端答题 |
| 热点行串行 | 库存拆分多行 / 全放 Redis | 业务层合并下单 |
| 读多写少 | 读写分离，读走从库 | 关键读走主库保证一致 |
| 主库被报表打挂 | 报表走 OLAP/独立从库 | 语句超时 max_execution_time |
| 连接数飙升 | 连接池控大小 + 清 Sleep 连接 | wait_timeout 回收 |
| 缓存与 DB 一致 | Cache Aside：更库后删缓存 | 延迟双删、binlog 同步 |
| 跨分片聚合 | 数据同步到分析库 | 中间件归并（慢） |
| 次要功能拖累主链路 | 远程降级开关 | 返回兜底数据 |
| 大促流量防线（外→内） | 挡掉什么 |
|---|---|
| 限流/排队/答题 | 无效请求、机器刷量 |
| Redis 缓存 | 读洪峰 |
| MQ 削峰 | 写洪峰 |
| 分库分表 | 单库写入上限 |
| 降级开关 | 边缘功能资源占用 |
13 常见坑与注意事项
1. 让主库扛报表：一个大查询拖垮整个交易，报表必须隔离到分析库。
2. 缓存更新而不是删除：并发写时容易脏，写后删缓存才稳。
3. 连接池越大越好：错。连接过多反而上下文切换拖慢吞吐，要按 CPU 核数设。
4. 压测用空库：数据量和生产不一致，压测结果毫无参考价值。
5. 降级开关要发版：大促时开关必须远程秒级生效，改代码来不及。
6. 忽略主从延迟：下单后立刻读从库，用户看到"订单不存在"，要读己之写。
7. 战后不对账：削峰异步链路必然有少量不一致，不对账就是埋雷。
8. 热点行不拆分：所有更新挤一行锁，再强的机器也被串行化卡死。
14 练习题与自测
练习 1：秒杀 1000 件商品面对 10 万并发，说出你的三层防线。
参考答案：① 前端限流/答题挡机器人；② Redis 原子预扣库存拦读；③ 抢到额度的请求发 MQ 异步落单，DB 只平缓消费。
练习 2：热点商品库存挤在一行导致行锁串行，怎么优化？
参考答案：把单行库存拆成多行分片（如 10 片），扣减时随机落片分散锁竞争；或库存全放 Redis，DB 只做对账兜底。
练习 3：读写分离后用户刚下单却查不到订单，是什么原因？怎么解？
参考答案：主从延迟导致读从库读到旧数据；解法是下单后短时间内"读己之写"强制走主库，或等从库追位点。
练习 4：大促时 Threads_connected 逼近 max_connections，你怎么处理？
参考答案：先看 Threads_running 而非 connected；清理 Sleep 连接、调小 wait_timeout、应用侧收窄连接池，必要时临时调高 max_connections 并扩容。
练习 5（自测）：画出大促数据库的分层防线（从接入到数据库共 5 层），并说出每层挡掉的是什么流量。
自测要点：能否说出限流挡刷量、缓存挡读、MQ 挡写洪峰、分库分表分散单库、降级保核心这五层。
下一篇预告：第 24 章 亿级数据表设计与迁移
文章回复
0 条公开回复