1.5.7 分库分表与扩容迁移

你完成本册后，能把“单库为什么不够、怎样选分片键、跨库能力损失了什么、如何不停机扩容”讲成一条可验证的工程证据链；案例统一落到 WMS（仓储管理系统）库存、订单履约和支付资金一致性。

1. 先给结论：分片解决边界，不解决所有问题

flowchart LR
    A[单库指标逼近边界] --> B{先定位瓶颈}
    B -->|表/索引过大| C[垂直拆分]
    B -->|写入或容量持续增长| D[水平分片]
    B -->|少数租户或仓库过热| E[热点隔离]
    C --> F[路由、约束与迁移设计]
    D --> F
    E --> F

1.1 为什么分库分表：容量、吞吐和热点是三条独立边界

分库分表不是“表大了就拆”的口号，而是把一个单点的容量、写入吞吐和热点竞争边界拆开。容量边界表现为数据、二级索引、历史归档和备份恢复时间持续增长；吞吐边界表现为 CPU（中央处理器）、磁盘 I/O（输入输出）、日志刷盘、复制延迟或连接数长期接近阈值；热点边界表现为少数仓库、商家、商品或支付渠道把同一行、同一分区或同一实例打热。只读副本只能分担读，缓存只能削减可缓存读，二者都不能让同一热点库存扣减并行化。

先定义业务服务目标：例如订单履约库单实例安全容量 8 亿行、日增 1 200 万行、峰值写入 8 000 TPS（每秒事务数）、主从延迟告警为 3 秒；再以 6 至 12 个月预测判断是否要演进。WMS（仓储管理系统）的库存可用量更新通常是强一致热写，支付账务是不可丢失、不可重复的资金事实，均不能仅靠“多加机器”回答。分片的价值是把独立键空间放到不同资源池，但同一分片内仍有锁、索引、日志和故障域。

边界	先看证据	可采用的手段	不应误判为
容量	行数、索引大小、备份时长、恢复目标	归档、垂直拆分、水平分片	单纯慢 SQL（结构化查询语言）
吞吐	TPS（每秒事务数）、刷盘、复制延迟、连接池	优化写路径、分片、削峰	只加读副本
热点	Top N（前 N）键、锁等待、分片倾斜	热点隔离、键重设计、队列合并	平均负载问题
可用性	故障半径、切换时间、恢复演练	高可用、备份、隔离	分片天然高可用

数据演绎 1：是否已经跨过单库容量边界

订单主表当前 3.2 亿行，数据与索引合计 1.9 TiB（太字节），日增 900 万行、约 52 GiB（吉字节）；按 70% 安全水位，目标实例可承载 3 TiB（太字节），剩余 1.1 TiB（太字节），理论窗口约为 1 126 / 52 = 21.7 天。即使磁盘还能扩，也要把全量备份、恢复校验、二级索引重建和副本追赶纳入窗口。结论不是“明天立刻拆”，而是本周冻结分片键和迁移方案，先清理可归档历史数据；若归档后净增长仍超过 35 GiB（吉字节）/天，则按四分片目标实施。这里容量告警来自未来窗口，而不是某次磁盘报警。

1.2 为什么先垂直后水平：先消除耦合，再扩大键空间

垂直拆分按领域职责切开表或库，例如把订单核心状态、履约轨迹、附件检索、商家配置、支付账务分成不同边界；水平分片则把同一逻辑表按分片键拆成多份。通常先垂直后水平，因为前者先让读写模型、生命周期、容量和一致性边界可见，避免把本来不该放在一起的数据一起复制到每个分片。订单表若同时承载下单状态、长文本、轨迹、营销标签和对账字段，先按职责拆开，往往就能显著缩小热表与索引。

不能机械地说“永远先垂直”。如果单一订单核心表已因日增和写吞吐达到硬边界，且领域拆分不能降低核心写入，就应并行完成水平方案。但水平分片前至少要明确哪些表随订单同分片、哪些是全局配置、哪些应独立服务，否则跨库 join（连接）会从设计问题变成日常查询问题。

拆分方式	切分依据	先解决什么	常见风险	WMS（仓储管理系统）示例
垂直拆分	领域、访问频率、生命周期	宽表耦合与资源互扰	跨服务调用增多	库存、商品、履约轨迹分开
垂直分库	强一致边界与权限	故障和变更隔离	分布式事务增多	支付账务独立
水平分表	同类记录的分片键	单表索引与容量	路由和跨表聚合	订单按商家拆表
水平分库	分片键空间与资源池	单实例写吞吐	跨库语义丢失	订单按商家路由到库

数据演绎 2：垂直拆分为何能推迟水平分片

订单宽表 1.9 TiB（太字节）中，履约轨迹与附件索引占 1.05 TiB（太字节），查询却只占 6%；营销扩展字段占 0.32 TiB（太字节），写入时还维护 5 个二级索引。先把轨迹、附件和营销扩展移到独立表后，核心订单表降到 0.53 TiB（太字节），每次状态更新维护的索引从 8 个降到 3 个，写放大明显下降。若核心订单日增仍为 450 万行，则以 4 个水平分片承接；如果不先垂直拆，4 个分片会各自携带几乎不访问的大字段和索引，迁移时间、成本和回滚复杂度都放大。

1.3 分片键选择：让大多数写入、查询和关联在同一分片完成

分片键应同时满足四个条件：高频写入能定位、常用查询能携带、数据分布相对均衡、未来扩容可迁移。候选键不能只看基数；高基数的订单号若查询常按商家、仓库或用户发起，仍会导致广播。反过来，商家键容易让订单、履约、售后同片，但头部商家会形成倾斜，需预留“商家 + 虚拟分片”或热点商家独立映射。

WMS（仓储管理系统）库存的分片键可优先是 warehouse_id（仓库标识） + sku_id（库存单元标识） 的归属规则，但库存扣减必须保证同一库存事实稳定落在一个分片；订单可按 merchant_id（商家标识） 或订单归属路由；支付不应因订单号哈希就丢失渠道流水唯一性。分片键一旦作为数据位置真相，就不能轻易改；可扩容的设计通常先引入虚拟桶，再映射到物理库表。

候选键	优点	主要缺陷	适用判断
`order_id（订单标识）` 哈希	均衡、点查直接	商家列表和履约关联易广播	订单号是主访问入口
`merchant_id（商家标识）`	订单链路易同片	头部商家热点	多数请求带商家
`warehouse_id（仓库标识）`	库存和出库同片	大仓热点	仓内事务占主导
`user_id（用户标识）`	用户订单列表自然	运营按商家查询昂贵	消费者业务为主
时间	归档和冷热简单	当前分区易热、其他查询广播	时间范围是主入口

数据演绎 3：用虚拟桶识别并处理头部商家

设 1 024 个虚拟桶、16 个物理分片，普通商家按 hash(merchant_id) mod 1024 落桶，再由桶映射到物理分片。总写入 16 000 TPS（每秒事务数），平均每片应为 1 000 TPS（每秒事务数），但商家 M100 独占 2 400 TPS（每秒事务数），其所在分片达到 3 100 TPS（每秒事务数），其他 15 片平均仅 860 TPS（每秒事务数）。不能直接把所有桶重哈希；应把 M100 的若干虚拟桶或专属映射迁到新分片，并让路由元数据按版本生效。迁后新分片 2 400 TPS（每秒事务数），原片回落到 700 TPS（每秒事务数），同时仍要检查单商品库存热键，因为商家拆走不等于库存锁冲突消失。

1.4 路由与全局 ID（全局唯一标识）：数据位置必须可解释、可回放

路由是从业务键、路由版本和映射元数据确定物理库表的过程。写请求必须带确定分片键或先通过唯一索引服务查询归属；读请求优先携带分片键，缺失时只能走受控的索引表、搜索模型或异步数仓，不能默默广播。路由结果要记录 route_version（路由版本）、逻辑分片与物理位置，才能在灰度迁移、重试和故障回放中解释“这条订单为什么写到这里”。

全局 ID（全局唯一标识）至少要全局唯一、趋势有序或可接受、可独立生成且不泄露敏感业务量。数据库自增 ID（标识）在多库下会冲突且路由未知；UUID（通用唯一标识）唯一但随机性会影响索引局部性；Snowflake（雪花算法）类 ID（标识）兼顾趋势与分布式生成，但要治理时钟回拨、机器标识和解析边界。业务单号与主键要分开：支付渠道流水、商户订单号分别有自己的唯一和幂等语义。

路由或 ID（标识）方案	优点	风险	工程控制
应用计算路由	透明、性能可控	规则散落	路由库与版本化 SDK（软件开发工具包）
中间件路由	接入改造小	复杂 SQL（结构化查询语言）限制	明确支持矩阵与压测
自增 ID（标识）分段	简单、顺序好	发号服务和段耗尽	高低水位预取
Snowflake（雪花算法）ID（标识）	本地生成、高并发	时钟和节点治理	时钟监控、节点租约
UUID（通用唯一标识）	无中心依赖	索引随机写、长度大	选择有序变体或二进制存储

数据演绎 4：路由版本避免扩容时写错位置

订单 O900 的商家落在虚拟桶 513。旧路由版本 V1（版本一）将桶 513 指向 db03（数据库三），新版本 V2（版本二）将其指向 db17（数据库十七）。迁移灰度期间，读先按订单中持久化的 route_version（路由版本） 找到 V1（版本一）或 V2（版本二），写则由迁移状态决定双写或新写。若一个重试请求只按“当前 V2（版本二）”路由，会把本应更新旧库的订单写入新库，制造双事实。正确做法是订单创建时固定归属，迁移控制面显式改变状态，所有写入携带幂等键和位置版本。

1.5 跨库分页、排序、聚合与 join（连接）：先改变查询模型，再谈技术补救

flowchart TD
    A[带分片键的查询] --> B[单分片 SQL（结构化查询语言）]
    C[跨片列表/报表] --> D[异步宽表或数仓]
    E[少量跨片聚合] --> F[受限广播与应用归并]
    G[跨片 join（连接）] --> H[同片绑定或反范式索引]
    B --> I[稳定排序键与游标]
    F --> I

水平分片后，数据库原生的全局排序、分页、聚合和 join（连接）不再天然成立。对每个分片取 limit offset + size 再归并，看似正确却会使深分页的扫描量按分片数倍增，且并发写入下容易重复或漏读。在线列表应优先要求分片键，并用 created_at（创建时间） + id（标识） 这样的全局稳定排序键做 keyset pagination（游标分页）；运营全局报表应走异步汇总、搜索模型或数仓；少量受控跨片查询才可取每片 Top K（前 K 条）后在应用层归并。

跨库 join（连接）优先改为绑定表同片、冗余必要字段或先查定位索引再点查，不应把中间件的广播 join（连接）作为日常主路径。比如订单和订单项以同一 order_id（订单标识） 规则同片，订单列表所需的商家展示名在订单快照中冗余；支付详情由支付标识定位，不在订单搜索页做实时多库连接。

需求	推荐模型	可接受的在线代价	禁忌
订单详情	带订单路由键点查	一个分片	先广播再过滤
商家订单列表	商家同片、游标分页	一个分片顺序扫描	大偏移分页
全站运营排行	异步聚合或数仓	秒级或分钟级延迟	实时扫所有分片
小范围跨片审计	并发受限归并	明确分片上限	无上限 `IN（属于）`
订单与订单项	绑定表同路由	单片 join（连接）	不同键独立散列

数据演绎 5：深分页为何会把 20 行变成 16 万次读取

16 个分片的全站订单列表请求第 10 001 页，每页 20 条。偏移分页需每片取前 10 000 × 20 + 20 = 200 020 条，理论候选为 3 200 320 条，再归并后只返回 20 条；即使索引覆盖，也会消耗网络、内存和数据库扫描预算。改用携带上页最后 (created_at, id) 的游标，每片只需向后取 20 至 40 条候选，最坏约 640 条再归并。若产品必须任意跳页，应使用异步检索索引或固定快照任务，而不是让交易库承担无限深度翻页。

1.6 唯一约束、广播表与绑定表：把全局规则显式化

唯一约束只在一个物理表内生效。分片后 unique(email)、unique(channel_trade_no) 这类业务不变量若不设计全局归属，就会在不同分片重复。方案包括把唯一键作为路由键、维护全局唯一索引表、由专用号段或登记服务分配，或者在业务允许时把唯一性范围限定为租户内。支付渠道流水必须全局或渠道范围内唯一，不能只靠应用先查询后插入；WMS（仓储管理系统）的库存预占请求号也需要在其归属分片内由唯一索引兜底。

广播表是每个分片都保存的一小份、低频变化且读多的数据，如国家码、仓库静态配置或字典；写入必须可靠传播并有版本校验，不能放高频可变余额。绑定表是一组拥有相同分片键和同一算法的表，例如订单、订单项、履约子任务，使它们在同一物理分片内 join（连接）。绑定不是外键替代：仍需定义删除、状态推进和异常补偿。

对象	分片后做法	一致性要求	典型误区
渠道支付流水	全局登记或渠道归属唯一	强幂等	每个订单库各建唯一键
商家内订单号	`merchant_id（商家标识）` 同片唯一	租户内强唯一	误称全局唯一
国家码字典	广播表加版本	最终一致可控	当成余额表复制
订单与订单项	绑定表同路由	单片事务	只按各自主键散列
库存预占流水	库存归属片唯一	强幂等	先查后插无约束

数据演绎 6：支付回调重复如何穿透双写窗口

渠道回调 T20260714001 到达两次：第一次在旧分片写入支付流水并发布事件；迁移双写期间第二次到达，应用先以渠道流水在全局登记表原子占位，返回已处理，再根据登记的支付归属定位旧片或新片。若只在每个支付分片上建唯一索引，双写时两个库都可能各插入一条成功流水，资金与订单都会重复推进。正确验收包括“登记表一条、支付事实一条、订单支付事件至多生效一次”，三者任何不一致都进入对账。

1.7 读写分离与一致性读：副本是性能策略，不是正确性来源

flowchart LR
    A[支付回调/库存扣减] --> B[主库单片事务]
    B --> C[binlog（二进制日志）复制]
    C --> D[只读副本]
    E[刚写后查询] --> B
    F[列表和非关键查询] --> D
    G[副本延迟超阈值] --> H[降级主库或返回可解释延迟]

读写分离把可容忍延迟的读导向副本，不能改变写入事实的唯一归属。支付回调、库存扣减、订单状态条件更新必须走主库；用户刚提交订单后查看结果、支付成功后的确认页、后台对账基线也通常要读主库或使用会话一致性策略。复制延迟时，副本可能读到旧订单状态，若应用据此再次扣减或重复入账，就会产生业务错误。

实现上可按请求语义加读路由标签，或在写后保存 GTID（全局事务标识）/时间窗并等待副本追平；更保守的做法是关键链路固定主读。不要把“读到了副本”隐藏在数据访问层，调用方必须知道本次读取是否允许陈旧。分片后每个逻辑分片都有主从拓扑，延迟、故障切换和读流量也要按分片监控。

场景	读位置	原因	降级策略
库存扣减后确认	主库	必须读到本次条件更新	主库限流而非读副本
支付回调幂等判断	主库	不能读陈旧流水	重试与查单
订单历史列表	副本可选	允许短暂延迟	标识数据更新时间
运营报表	副本或数仓	不参与交易决策	延迟告警
对账任务	主库快照或一致备份	需要明确基线	分批、限速

数据演绎 7：副本延迟 5 秒如何制造重复扣减

库存主库已将可用量从 1 扣到 0，并写入预占流水；副本因 5 秒延迟仍显示可用量 1。若下一个请求先从副本“预检查有库存”，再对主库执行无条件更新，便会把库存扣成负数；即使主库条件更新拦住，用户仍会经历错误提示和重试风暴。正确路径是主库直接执行条件更新，以受影响行数判断成功；副本仅用于不影响决策的展示。这个例子说明读写分离不能替代原子条件写。

1.8 ShardingSphere（分库分表中间件）、MyCat（数据库中间件）与应用路由对比

选型不是谁“功能多”就选谁，而是看 SQL（结构化查询语言）形态、团队可控性、迁移能力与故障模型。Apache ShardingSphere（分库分表中间件）可在 JDBC（Java 数据库连接）层或代理层提供分片、读写分离、分布式主键和部分分布式事务能力，适合 Java（编程语言）生态中希望规则集中、应用改造可控的场景；MyCat（数据库中间件）以数据库代理方式接入，便于对多语言应用透明，但代理本身成为容量、兼容性和故障域的一部分；应用路由把路由逻辑和数据访问模型显式放在服务内，性能和可解释性最好，却要求各服务严格复用规则库并承担治理。

不论选哪种，广播查询、复杂 join（连接）、全局排序、事务和迁移都受数据物理边界约束。中间件能改写 SQL（结构化查询语言）并归并结果，却无法免费创造跨库原子性或消除网络成本。先用真实 SQL（结构化查询语言）分类：单片点查比例、广播上限、写事务形态、在线变更和故障演练，再做压测和灰度。

方案	主要优势	主要代价	适合的团队边界
ShardingSphere（分库分表中间件）JDBC（Java 数据库连接）	应用内可观测、规则集中	依赖接入和兼容矩阵	Java（编程语言）服务统一
ShardingSphere（分库分表中间件）Proxy（代理）	协议接入相对透明	新代理故障域	多语言且运维成熟
MyCat（数据库中间件）	改造路径直观	代理性能与 SQL（结构化查询语言）限制	既有代理经验
应用路由	位置显式、定制强	每个服务需治理	领域边界清晰、平台能力强

数据演绎 8：广播率决定中间件不是“零改造”

抽样一周订单接口：1 000 万次请求中，带商家或订单路由键的占 9 850 万次，缺失路由键的全局检索占 150 万次。若有 32 个分片，后者会产生 4 800 万次物理查询，平均每个逻辑请求放大 32 倍；即使中间件自动归并，数据库和网络仍承担真实成本。先把这 1.5% 的接口改为检索索引、强制筛选或异步报表，收益远大于替换中间件。验收指标应是广播率从 1.5% 降到 0.05% 以下，而不是仅验证代理能返回结果。

1.9 扩容迁移总原则：回填、追增量、校验、灰度、切流、回滚缺一不可

sequenceDiagram
    participant O as 旧分片
    participant C as CDC（变更数据捕获）
    participant N as 新分片
    participant R as 路由控制面
    O->>N: 主键分段回填
    O->>C: binlog（二进制日志）持续变更
    C->>N: 幂等重放并记录位点
    N-->>R: 校验通过
    R->>R: 灰度开启双写与影子读
    R->>N: 切换指定虚拟桶
    alt 指标越界或差异
        R->>O: 回退旧路由版本
    else 稳定窗口结束
        R->>O: 旧数据只读保留后下线
    end

不停机迁移不是把旧库停掉、导出、导入、新库开机，而是让旧库在服务期间成为权威源，目标库先承接历史快照，再通过 CDC（变更数据捕获）消费 binlog（二进制日志）追上增量。只有当目标位点追平、结构一致、数据校验和业务不变量校验均通过时，才进入双写和灰度读；切流按虚拟桶或租户小批次执行，并保留旧路由、旧数据和可回放日志直到稳定窗口结束。

迁移控制面至少维护迁移范围、快照起点、CDC（变更数据捕获）位点、源目标校验状态、双写状态、读写路由版本、切流比例和回滚阈值。回滚不是“把新库删掉”，而是停止扩大切流、把未确认的路由回到旧版本，同时保留已经产生的双写证据，以便修复差异。若已在新库独占写入，则回滚必须说明反向同步与冲突策略，不能口头承诺一键回退。

阶段	目标	必要证据	失败动作
准备	锁定范围与不变量	结构、索引、路由、阈值清单	不满足即不开始
回填	搬运历史快照	主键水位、批次记录、限速	断点续传
追平	消费所有增量	位点差、延迟、失败队列	重放或修复位点
双写	验证双目标一致	幂等键、双写成功率	降级旧写并补偿
灰度切流	验证真实请求	差异率、P99（百分之九十九分位）、错误率	路由回退
收尾	删除旧依赖	稳定窗口对账、备份	延后下线

数据演绎 9：以位点差而不是“迁移跑完了”判断是否可切流

回填任务在 02:00 读到源库快照水位 L100，完成 8 000 万行后，CDC（变更数据捕获）已消费到 L180；此时源库最新位点为 L185，仍有 5 个日志事务未应用，且其中包含订单状态从“待支付”改为“已支付”。若只比较行数，源目标都是 8 000 万行，仍会漏掉状态更新。应等待目标成功应用至至少 L185，并再取一个稳定观测窗口确认源、目标位点差为零；同时检查死信、重复消费、DDL（数据定义语言）变更和长事务延迟，才允许下一阶段。

1.10 双写、影子读与灰度切流：双写是迁移阶段，不是长期架构

flowchart TD
    A[请求含幂等键与路由版本] --> B{迁移状态}
    B -->|旧写| C[只写旧分片]
    B -->|双写| D[旧分片主写]
    D --> E[新分片幂等写]
    B -->|新写灰度| F[新分片主写]
    E --> G[影子读/异步比对]
    F --> G
    G --> H{差异或阈值越界}
    H -->|是| I[停止扩大并回退路由]
    H -->|否| J[扩大下一批桶]

双写的难点不在“调用两次写入”，而在部分成功、重试乱序、超时未知和重复事件。必须先定义主写权威：常见做法是旧分片先完成本地事务，新分片按全局 ID（全局唯一标识）或业务请求号幂等写入；如果副写失败，记录可靠待补任务和告警，不把请求悄悄当成功。双写期间禁止基于新库的陈旧读做交易决策，影子读只用于比对结果，不返回给用户。

灰度切流按虚拟桶、商家或仓库逐批推进，每批都观察写成功率、双写差异、读结果差异、P99（百分之九十九分位）、复制延迟和资金/库存不变量。新写阶段必须明确旧库是否仍同步：若保留反向同步，复杂度高但回退容易；若停止旧写，则回退不再是无损动作，需要把新写反向补回或把这批视为不可回退边界。工程上优先把“可回退窗口”限定在双写期，并避免过早结束旧数据保留。

模式	写权威	读权威	适用阶段	关键风险
旧写 + 新副写	旧分片	旧分片	初始双写	新写漏补
旧写 + 影子读	旧分片	旧分片	校验	影子流量过大
新写 + 旧副写	新分片	新分片	可控切流	回退需确认旧追平
新写单写	新分片	新分片	稳定后	不能直接回退

数据演绎 10：双写 99.99% 成功仍不能忽略失败尾部

某订单桶每小时 300 万次状态写入，副写成功率 99.99%，看似只失败 0.01%，实际每小时约 300 条新分片缺失。若不记录请求号与补偿队列，24 小时会积累 7 200 条差异，其中可能包含支付确认或库存释放。正确阈值不是“成功率看起来很好”，而是副写失败必须可定位、可重放，未补差异数在 0 或明确受控上限；切流前要求连续两个观测窗口差异归零，并按业务类型抽样核验状态机。

1.11 数据校验与业务对账：行数一致只是最低门槛

flowchart LR
    A[结构与索引校验] --> B[分桶行数校验]
    B --> C[主键/版本校验和]
    C --> D[业务不变量校验]
    D --> E[抽样明细回放]
    E --> F{差异归零？}
    F -->|否| G[差异队列：定位、重放、复核]
    G --> B
    F -->|是| H[允许扩大灰度]

迁移校验分四层。第一层是结构：字段类型、字符集、默认值、索引、唯一约束、分区和触发器是否与迁移设计一致。第二层是物理数据：按逻辑桶、主键范围或日期分段比较行数、最大更新时间、校验和，而不是只比较总数。第三层是语义数据：订单状态机是否只允许合法转换，库存是否满足余额不变量，支付借贷/收付是否平衡。第四层是链路：从请求号追到事件、订单、履约、支付和对账结果，验证重复、删除、软删除和异常补偿都可解释。

校验任务必须可重复、可限速、可记录版本。对大表不可一次全表 checksum（校验和） 把主库打满，可按虚拟桶和时间窗口在副本或一致快照上执行，并把差异落入专门队列。差异修复也必须幂等：明确源为准、重放哪条变更、是否保留审计记录，不能用“目标覆盖源”掩盖真实写入问题。

校验层级	比较对象	能发现什么	不能证明什么
结构	DDL（数据定义语言）、索引、约束	漏字段、漏索引、类型漂移	业务状态正确
物理	分桶行数、主键、版本、校验和	漏行、重复、旧版本	金额语义正确
不变量	库存、资金、状态机	关键业务错误	所有展示字段一致
链路	请求到事件到事实表	幂等和补偿断点	全量统计准确

数据演绎 11：库存余额相等仍可能隐藏预占差异

源、目标两个仓库分片的库存余额都显示“可用 1 000、冻结 200”，行数和余额校验均通过；但源库有 200 条预占流水，目标库只有 198 条，其中两条各 10 件的预占被另一条调整流水抵消，所以总额碰巧一致。若只比余额，后续取消订单会在目标库找不到预占而无法释放。业务校验应同时验证 可用 + 冻结 + 已售调整 的守恒关系、预占流水请求号集合、每条流水的版本和关联订单状态，才能确认迁移正确。

1.12 扩容后的热点治理、回滚边界与线上排查

flowchart TD
    A[告警：延迟/差异/锁等待] --> B{先定影响桶与版本}
    B --> C[查路由、迁移状态、主从角色]
    C --> D{数据差异？}
    D -->|是| E[停止扩大、回退未确认桶、保全位点]
    D -->|否| F{热点或资源饱和？}
    F -->|是| G[识别 Top N（前 N）键、限流、热点隔离]
    F -->|否| H[查 SQL（结构化查询语言）广播、连接与代理]
    E --> I[对账、重放、复核]
    G --> I
    H --> I

扩容完成不是终点。要持续按逻辑桶而非只按实例均值观察容量、TPS（每秒事务数）、P99（百分之九十九分位）、锁等待、慢 SQL（结构化查询语言）、复制延迟、广播率、双写遗留和对账差异。热点可能来自头部商家、单仓库爆款、分片规则倾斜、全局序列、代理连接池或迁移校验任务；先确认热点是否集中在同一业务键，再选限流、隔离、拆桶、队列合并或索引优化，不能只横向加库。

回滚边界要在切流前声明。对尚处旧写 + 新副写阶段的桶，路由回退相对简单；对已新写且旧库不再同步的桶，回退需要反向复制、冲突处理和重新对账，可能不再满足快速恢复目标。线上排查先冻结扩大范围，保存路由版本、请求号、binlog（二进制日志）位点、差异样本和指标时间线，再做定向止血。任何人工修数都必须有审批、审计和二次校验。

现象	首要证据	可能根因	安全动作
单桶 P99（百分之九十九分位）升高	桶 TPS（每秒事务数）、热键、锁等待	头部商家或热库存	限流、隔离、短事务
切流后查询为空	路由版本、索引位点、影子差异	路由错配或未追平	回退该桶、补数据
对账差异增长	请求号、事件位点、双写队列	副写失败或重放乱序	停扩、重放、复核
广播率升高	SQL（结构化查询语言）标签、分片数	新接口缺路由键	限制接口、建索引模型
副本延迟升高	每片复制延迟、校验任务负载	回填/校验抢资源	限速、主读保护

数据演绎 12：扩容后平均均衡但单桶仍失火

扩容至 32 个物理分片后，实例平均 CPU（中央处理器）从 68% 降到 31%，但桶 513 的订单 P99（百分之九十九分位）仍为 1.8 秒，且该桶的库存行锁等待占全局 72%。查看 Top N（前 N）键发现一个仓库爆款每秒 1 200 次预占，所有请求仍落到同一 warehouse_id（仓库标识） + sku_id（库存单元标识）。此时再迁桶只能把热点从一个实例搬到另一个实例；应先对该库存采用队列合并、按批次或库存桶拆分、限购和条件更新，并以余额守恒与成功率验证。结论：分片均衡是资源均衡，不等于单业务键可并行。

2. 综合题库演练过渡（非知识型）

下面七图只用于组织口述路径，不新增知识结论。你先说明业务边界和数据位置，再说明约束、迁移证据与回滚条件，避免把中间件能力误说成业务正确性。

flowchart LR
    A[容量告警] --> B[归档与索引治理]
    B --> C{仍无法满足恢复窗口？}
    C -->|是| D[垂直拆分]
    C -->|否| E[暂缓分片并持续监控]
    D --> F[水平分片]

flowchart TD
    A[订单宽表] --> B[订单核心]
    A --> C[履约轨迹]
    A --> D[附件与检索]
    A --> E[支付账务]
    B --> F[按归属键分片]
    C --> G[按生命周期归档]

flowchart LR
    A[业务请求] --> B[分片键]
    B --> C[虚拟桶]
    C --> D[路由版本]
    D --> E[物理库表]
    E --> F[本地约束与事务]

flowchart TD
    A[缺少分片键的查询] --> B{是否交易主链路？}
    B -->|是| C[补充定位索引或改接口]
    B -->|否| D[异步检索或报表]
    C --> E[单片点查]
    D --> F[受限跨片归并]

flowchart LR
    A[业务唯一键] --> B{能作为路由键？}
    B -->|能| C[同片唯一索引]
    B -->|不能| D[全局登记索引]
    C --> E[本地事务]
    D --> F[幂等占位与对账]

flowchart TD
    A[迁移准备] --> B[快照回填]
    B --> C[增量追平]
    C --> D[数据校验]
    D --> E[双写与影子读]
    E --> F[分桶灰度切流]
    F --> G[稳定窗口与下线]
    F -.异常.-> H[路由回退与差异修复]

flowchart LR
    A[按桶监控] --> B[容量与吞吐]
    A --> C[热点与锁等待]
    A --> D[广播率]
    A --> E[迁移差异]
    B --> F[扩容决策]
    C --> G[热点隔离]
    D --> H[查询模型治理]
    E --> I[停止扩大并对账]

3. 分库分表与迁移综合题库

每题均绑定本册真实小节与知识图谱入口。答题先给结论，再给数据或路由证据，最后说明验证与回滚。

问题（综合题）：为什么要分库分表，而不是先升级单机？
- 口述答案：我会把“为什么要分库分表，而不是先升级单机？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“为什么要分库分表，而不是先升级单机？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第1题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复也必须留下审批、前后值与二次核验记录。
- 对应机制详解
- 追问树：
  - 若“为什么要分库分表，而不是先升级单机？”中的权威位置不可用，读写怎样降级？
  - 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
  - 若指标异常，先按哪个桶、位点或不变量缩小影响面？
问题（综合题）：为什么通常先垂直拆分，再做水平分片？
- 口述答案：我会把“为什么通常先垂直拆分，再做水平分片？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“为什么通常先垂直拆分，再做水平分片？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第2题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复也必须留下审批、前后值与二次核验记录。
- 对应机制详解
- 追问树：
  - 若“为什么通常先垂直拆分，再做水平分片？”中的权威位置不可用，读写怎样降级？
  - 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
  - 若指标异常，先按哪个桶、位点或不变量缩小影响面？
问题（综合题）：怎样选择订单、库存和支付的分片键？
- 口述答案：我会把“怎样选择订单、库存和支付的分片键？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“怎样选择订单、库存和支付的分片键？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第3题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复也必须留下审批、前后值与二次核验记录。
- 对应机制详解
- 追问树：
  - 若“怎样选择订单、库存和支付的分片键？”中的权威位置不可用，读写怎样降级？
  - 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
  - 若指标异常，先按哪个桶、位点或不变量缩小影响面？
问题（综合题）：分片后路由规则为什么必须版本化？
- 口述答案：我会把“分片后路由规则为什么必须版本化？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“分片后路由规则为什么必须版本化？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第4题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复也必须留下审批、前后值与二次核验记录。
- 对应机制详解
- 追问树：
  - 若“分片后路由规则为什么必须版本化？”中的权威位置不可用，读写怎样降级？
  - 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
  - 若指标异常，先按哪个桶、位点或不变量缩小影响面？
问题（综合题）：全局 ID（全局唯一标识）应怎样设计？
- 口述答案：我会把“全局 ID（全局唯一标识）应怎样设计？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“全局 ID（全局唯一标识）应怎样设计？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第5题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复也必须留下审批、前后值与二次核验记录。
- 对应机制详解
- 追问树：
  - 若“全局 ID（全局唯一标识）应怎样设计？”中的权威位置不可用，读写怎样降级？
  - 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
  - 若指标异常，先按哪个桶、位点或不变量缩小影响面？
问题（综合题）：跨库分页、排序和深翻页应怎样设计？
- 口述答案：我会把“跨库分页、排序和深翻页应怎样设计？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“跨库分页、排序和深翻页应怎样设计？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第6题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复也必须留下审批、前后值与二次核验记录。
- 对应机制详解
- 追问树：
  - 若“跨库分页、排序和深翻页应怎样设计？”中的权威位置不可用，读写怎样降级？
  - 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
  - 若指标异常，先按哪个桶、位点或不变量缩小影响面？
问题（综合题）：跨库聚合和 join（连接）为什么应改查询模型？
- 口述答案：我会把“跨库聚合和 join（连接）为什么应改查询模型？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“跨库聚合和 join（连接）为什么应改查询模型？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第7题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复也必须留下审批、前后值与二次核验记录。
- 对应机制详解
- 追问树：
  - 若“跨库聚合和 join（连接）为什么应改查询模型？”中的权威位置不可用，读写怎样降级？
  - 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
  - 若指标异常，先按哪个桶、位点或不变量缩小影响面？
问题（综合题）：分库分表后如何保证全局唯一约束？
- 口述答案：我会把“分库分表后如何保证全局唯一约束？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“分库分表后如何保证全局唯一约束？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第8题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复也必须留下审批、前后值与二次核验记录。
- 对应机制详解
- 追问树：
  - 若“分库分表后如何保证全局唯一约束？”中的权威位置不可用，读写怎样降级？
  - 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
  - 若指标异常，先按哪个桶、位点或不变量缩小影响面？
问题（综合题）：广播表和绑定表的适用边界是什么？
- 口述答案：我会把“广播表和绑定表的适用边界是什么？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“广播表和绑定表的适用边界是什么？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第9题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复也必须留下审批、前后值与二次核验记录。
- 对应机制详解
- 追问树：
  - 若“广播表和绑定表的适用边界是什么？”中的权威位置不可用，读写怎样降级？
  - 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
  - 若指标异常，先按哪个桶、位点或不变量缩小影响面？
问题（综合题）：读写分离如何避免读到旧数据？

口述答案：我会把“读写分离如何避免读到旧数据？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“读写分离如何避免读到旧数据？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第10题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“读写分离如何避免读到旧数据？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：ShardingSphere（分库分表中间件）、MyCat（数据库中间件）与应用路由如何选？

口述答案：我会把“ShardingSphere（分库分表中间件）、MyCat（数据库中间件）与应用路由如何选？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“ShardingSphere（分库分表中间件）、MyCat（数据库中间件）与应用路由如何选？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第11题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“ShardingSphere（分库分表中间件）、MyCat（数据库中间件）与应用路由如何选？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：为什么库存防超卖不能只靠分库分表？

口述答案：我会把“为什么库存防超卖不能只靠分库分表？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“为什么库存防超卖不能只靠分库分表？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第12题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“为什么库存防超卖不能只靠分库分表？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：支付资金一致性在分片系统中应坚持哪些边界？

口述答案：我会把“支付资金一致性在分片系统中应坚持哪些边界？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“支付资金一致性在分片系统中应坚持哪些边界？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第13题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“支付资金一致性在分片系统中应坚持哪些边界？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：为什么分布式事务不是默认答案？

口述答案：我会把“为什么分布式事务不是默认答案？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“为什么分布式事务不是默认答案？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第14题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“为什么分布式事务不是默认答案？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：最终一致性怎样做到可证明？

口述答案：我会把“最终一致性怎样做到可证明？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“最终一致性怎样做到可证明？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第15题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“最终一致性怎样做到可证明？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：不停机扩容迁移的完整步骤是什么？

口述答案：我会把“不停机扩容迁移的完整步骤是什么？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“不停机扩容迁移的完整步骤是什么？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第16题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“不停机扩容迁移的完整步骤是什么？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：回填与 CDC（变更数据捕获）怎样处理更新、删除和重复？

口述答案：我会把“回填与 CDC（变更数据捕获）怎样处理更新、删除和重复？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“回填与 CDC（变更数据捕获）怎样处理更新、删除和重复？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第17题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“回填与 CDC（变更数据捕获）怎样处理更新、删除和重复？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：双写出现部分成功、超时和乱序如何处理？

口述答案：我会把“双写出现部分成功、超时和乱序如何处理？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“双写出现部分成功、超时和乱序如何处理？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第18题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“双写出现部分成功、超时和乱序如何处理？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：影子读怎样设计，为什么不能直接返回新库结果？

口述答案：我会把“影子读怎样设计，为什么不能直接返回新库结果？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“影子读怎样设计，为什么不能直接返回新库结果？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第19题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“影子读怎样设计，为什么不能直接返回新库结果？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：迁移校验为什么要做行数、校验和和业务不变量？

口述答案：我会把“迁移校验为什么要做行数、校验和和业务不变量？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“迁移校验为什么要做行数、校验和和业务不变量？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第20题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“迁移校验为什么要做行数、校验和和业务不变量？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：库存迁移后怎样对账与修复差异？

口述答案：我会把“库存迁移后怎样对账与修复差异？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“库存迁移后怎样对账与修复差异？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第21题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“库存迁移后怎样对账与修复差异？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：支付迁移后怎样做资金对账？

口述答案：我会把“支付迁移后怎样做资金对账？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“支付迁移后怎样做资金对账？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第22题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“支付迁移后怎样做资金对账？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：怎样设计灰度切流和回滚阈值？

口述答案：我会把“怎样设计灰度切流和回滚阈值？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“怎样设计灰度切流和回滚阈值？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第23题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“怎样设计灰度切流和回滚阈值？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：扩容后单桶热点为什么不能只继续加库？

口述答案：我会把“扩容后单桶热点为什么不能只继续加库？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“扩容后单桶热点为什么不能只继续加库？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第24题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“扩容后单桶热点为什么不能只继续加库？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：如何控制广播 SQL（结构化查询语言）和查询退化？

口述答案：我会把“如何控制广播 SQL（结构化查询语言）和查询退化？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“如何控制广播 SQL（结构化查询语言）和查询退化？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第25题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“如何控制广播 SQL（结构化查询语言）和查询退化？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：路由错配或切流后查询为空，怎样排查？

口述答案：我会把“路由错配或切流后查询为空，怎样排查？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“路由错配或切流后查询为空，怎样排查？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第26题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“路由错配或切流后查询为空，怎样排查？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：怎样组织订单分片迁移上线值守？

口述答案：我会把“怎样组织订单分片迁移上线值守？”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“怎样组织订单分片迁移上线值守？”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第27题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“怎样组织订单分片迁移上线值守？”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

问题（综合题）：请完整复述 WMS（仓储管理系统）库存、订单履约、支付的协作方案。

口述答案：我会把“请完整复述 WMS（仓储管理系统）库存、订单履约、支付的协作方案。”先限定为数据归属、路由、约束和迁移证据共同构成的问题，而不是把分库分表当作万能答案。首先明确这个场景的权威数据在哪里、请求必须携带什么定位信息、本地事务能保护哪些记录；订单、库存、支付和履约各有自己的事实边界，跨片关系只能通过绑定表、定位索引或可靠事件协作。其次必须给出可复盘的数据演绎：按虚拟桶计算容量与写入，按业务键观察锁等待和尾延迟，或按请求号、数据版本与位点重放一次迁移链路。这样才能区分实例平均正常但单桶热点失火、数据行数相等但业务状态错误、以及位点已追平但查询语义不同三类问题。对“请完整复述 WMS（仓储管理系统）库存、订单履约、支付的协作方案。”还要主动说明失败分支：网络超时不能直接判失败，副本旧数据不能参与交易裁决，重复调用必须由幂等键拦住，双写部分成功与延迟消息必须保留补偿证据；一旦异常，先停止扩大范围，保全路由版本、日志位点和差异样本，再按权威事实做可审计重放。最后不能只以接口成功验收，要结合唯一约束、状态机、库存或资金守恒判断数据正确性，结合 P99（百分之九十九分位）、锁等待、广播率和复制延迟判断性能，结合分桶校验、影子差异和稳定窗口对账判断迁移安全。针对第28题，我还会让正常、重复、乱序和故障恢复四种输入同时通过该链路，比较最终位置、状态与流水是否一致；只有这些证据闭环，方案才具备上线、回滚和线上排障价值。任何人工修复必须留下审批、前后值、执行人、证据和二次核验记录，避免修复本身制造新差异。
对应机制详解
追问树：
- 若“请完整复述 WMS（仓储管理系统）库存、订单履约、支付的协作方案。”中的权威位置不可用，读写怎样降级？
- 若出现超时、重复或乱序，哪一个幂等键和版本可判定事实？
- 若指标异常，先按哪个桶、位点或不变量缩小影响面？

1.5.7 分库分表与扩容迁移

1. 先给结论：分片解决边界，不解决所有问题

1.1 为什么分库分表：容量、吞吐和热点是三条独立边界

数据演绎 1：是否已经跨过单库容量边界

热门面试题

1.2 为什么先垂直后水平：先消除耦合，再扩大键空间

数据演绎 2：垂直拆分为何能推迟水平分片

热门面试题

1.3 分片键选择：让大多数写入、查询和关联在同一分片完成

数据演绎 3：用虚拟桶识别并处理头部商家

热门面试题

1.4 路由与全局 ID（全局唯一标识）：数据位置必须可解释、可回放

数据演绎 4：路由版本避免扩容时写错位置

热门面试题

1.5 跨库分页、排序、聚合与 join（连接）：先改变查询模型，再谈技术补救

数据演绎 5：深分页为何会把 20 行变成 16 万次读取

热门面试题

1.6 唯一约束、广播表与绑定表：把全局规则显式化

数据演绎 6：支付回调重复如何穿透双写窗口

热门面试题

1.7 读写分离与一致性读：副本是性能策略，不是正确性来源

数据演绎 7：副本延迟 5 秒如何制造重复扣减

热门面试题

1.8 ShardingSphere（分库分表中间件）、MyCat（数据库中间件）与应用路由对比

数据演绎 8：广播率决定中间件不是“零改造”

热门面试题

1.9 扩容迁移总原则：回填、追增量、校验、灰度、切流、回滚缺一不可

数据演绎 9：以位点差而不是“迁移跑完了”判断是否可切流

热门面试题

1.10 双写、影子读与灰度切流：双写是迁移阶段，不是长期架构

数据演绎 10：双写 99.99% 成功仍不能忽略失败尾部

热门面试题

1.11 数据校验与业务对账：行数一致只是最低门槛

数据演绎 11：库存余额相等仍可能隐藏预占差异

热门面试题

1.12 扩容后的热点治理、回滚边界与线上排查

数据演绎 12：扩容后平均均衡但单桶仍失火

热门面试题

2. 综合题库演练过渡（非知识型）

3. 分库分表与迁移综合题库