阿里处理数十亿级交易，分库分表是后端工程师的基本功。这道题考察你在数据分片中做实际权衡的能力、处理迁移运维复杂度的能力，以及兼顾当前需求与未来增长的设计能力。
先分析查询模式：最常见的访问路径是什么？这决定最优分片键。
解释分片键选择：以user_id为主用于用户维度查询，以二级索引策略处理商家维度查询。
处理跨分片查询：分析类查询用scatter-gather，高频跨分片数据用反规范化或物化视图。
描述零停机迁移方案：双写、回填、验证、切读、停老写。
首先分析查询模式。订单表80%以上的查询按user_id（用户查自己的订单），15%按merchant_id（商家管理订单）。选择user_id为主分片键，用一致性哈希配1024个虚拟分片映射到16个物理库——这样扩容时只需重新映射虚拟分片，无需大规模数据迁移。商家维度查询通过binlog订阅异步维护一张按merchant_id分片的反规范化merchant_orders表。迁移分四个阶段：（1）双写：新订单同时写入新旧库，用TDDL的影子路由。（2）回填：批量任务迁移历史数据并校验checksum。（3）验证：对两套系统做影子读对比结果一致性。（4）切换：逐步将读流量切到新分片库（10%→50%→100%），然后停止旧库写入。回滚方案：验证失败则停止新库双写并回切读流量。20亿行表整体迁移周期预计2-3周。
提到TDDL（阿里分布式数据库中间件）展示你了解阿里技术栈。
一致性哈希加虚拟分片是业界最佳实践——实现扩容无需全量数据迁移。
迁移方案一定要包含回滚计划。
OceanBase适合很多场景，但对于访问模式清晰的超大规模表，通过TDDL做应用层分片能更精细地控制数据分布和查询路由。实践中阿里两种方案都在用，针对不同场景。
跨分片的分析类查询不应该打到事务型分片库。通过binlog将订单事件流到AnalyticDB或Elasticsearch等分析存储中，专门优化全扫描查询。