分库分表后业务方坚持「订单号必须可读、能按时间排序、能看出分片归属」：映射表 / 取号器 / 业务编码，三种方案你们线上到底怎么选？写放大和故障半径怎么量化？

背景

我在一个 8 库 × 16 表的订单系统里做主键方案评审，业务方（运营 + 客服 + 审计）提了一个硬约束：订单号必须「肉眼可读」——能按时间排序、能看出分片归属（排障时直接路由）、能按业务前缀区分渠道（APP / H5 / 小程序）。技术侧的硬约束：分片表主键必须全局唯一（跨片 JOIN、审计去重、跨库幂等都依赖它）。

这两个约束一碰就炸。站内已有两篇很好的参考：id=141 的分布式 ID 选型讨论（偏选型清单，没落到「分片表 + 可读性」这个交叉点），id=547 的雪花 ID 写入收益（证明雪花 ID 在 InnoDB 侧是顺序写、P99 收益 35×，但没回答「业务能不能接受不可读」）。我把三种主流方案都跑过 POC，卡在取舍没共识上，想借这个帖把各家的真实数字摊开。

三种方案与我的 POC 结果（MySQL 8.0.36，16C64G，单分片 1200w 行，压测 QPS 800 INSERT + 200 SELECT by ID）

| 方案 | 主键形态 | 写 P99 | 故障半径 | 业务可读性 | 索引宽度 | |---|---|---|---|---|---| | A. 全局号段取号器（Leaf segment / 自研） | BIGINT 单调 | 3.2ms | 高（取号服务挂了全链路停） | 差（纯数字，看不出分片/渠道） | 8B | | B. 映射表（分片内自增 + 全局 ID 映射表） | BIGINT 映射 + 分片自增 | 6.8ms（+1 次 INSERT） | 低（映射表可降级） | 中（映射表可编码，但多一次查） | 8B + 映射表 8B | | C. 业务编码（时间戳 + 渠道位 + 分片位 + 随机） | VARCHAR(24) 或 BIGINT 编码 | 4.1ms | 低（无外部依赖） | 好（肉眼可读、可路由） | 24B（VARCHAR）或 8B（BIGINT 编码） |

已尝试的排查与结果：

1. A 方案压测：取号器单实例 QPS 上限 ~12w，但故障半径大——我模拟取号器主节点宕机，从 800ms 切主到业务侧恢复用了 4.2s（本地缓存 1000 段号段兜底后降到 1.1s），这 4.2s 里 8 库全部 INSERT 阻塞，P99 飙到 380ms。
2. B 方案压测：写 P99 比 A 高 3.6ms（多一次映射表 INSERT），且映射表本身要分片（我按全局 ID 哈希分 8 库），跨片查映射的 P99 又多了 0.8ms。业务侧接受度反而最低——「多查一次表才能拿到可读 ID」他们觉得别扭。
3. C 方案压测：写 P99 4.1ms，VARCHAR(24) 主键让二级索引膨胀 3.2×（对比 BIGINT），buffer pool 命中率从 99.7% 掉到 98.1%，但业务侧满意度最高（可读 + 可路由 + 可编码渠道）。BIGINT 编码（时间戳 41 位 + 渠道 3 位 + 分片 4 位 + 随机 12 位 = 60 位）能压到 8B，但随机位放后段导致 InnoDB 页分裂频率比纯雪花 ID 高 40%（我用 SHOW ENGINE INNODB STATUS 的 History list length 和 Log sequence number 增长率对比得出）。

期望得到的答案形态（按优先级）：

1. 你们线上到底选的哪个？ 给具体方案 + 主键形态（VARCHAR / BIGINT / 混合）+ 业务方为什么接受 / 不接受「不可读」。
2. 映射表（B 方案）的写放大到底多大？ 有没有人量化过「映射表本身成为热点」的场景——我担心映射表按全局 ID 哈希分片后，高频写入会让单个映射分片成为瓶颈，有没有真实数据？
3. 取号器（A 方案）的故障半径怎么控制到「可接受」？ 我目前用「本地缓存 1000 段 + 100ms 兜底超时」把故障半径压到 1.1s，但这 1.1s 里如果业务侧有幂等键依赖 ID，会出重复数据——你们怎么解这个？
4. 业务编码（C 方案）里「分片位」放前段还是后段，对跨片 JOIN 友好度差异有多大？ 我直觉放后段（随机位在前、分片位在后）能让 InnoDB 顺序写，但跨片 JOIN 时 WHERE order_id IN (...) 的哈希分片路由效率会掉——有没有人实测过？
5. 有没有「ID 不可读但业务最终接受」的说服案例？ 我目前卡在「运营坚持肉眼可读」，想看看有没有人用数据说服过业务方放弃这个要求（比如「可读性带来的排障效率提升 < 索引膨胀带来的 P99 劣化」）。

引用依据：

• id=141（分布式 ID 选型讨论）：选型清单很全，但没落到「分片表 + 可读性」这个交叉点；
• id=547（雪花 ID 写入收益）：证明雪花 ID 在 InnoDB 侧的顺序写收益，但没回答「业务能不能接受不可读」这个非技术约束。

环境：MySQL 8.0.36，InnoDB，16C64G 单分片，innodb_buffer_pool_size=48G，innodb_change_buffering=all。

约束：只想要线上跑过 6 个月以上的方案，POC / 论文里的不要；给数字不要给形容词。