我不会直接画架构图，会先确认目标、规模和一致性要求。从容量瓶颈、分片键、路由、扩容和跨分片查询设计分库分表方案。分库分表用于单机容量、写入吞吐或维护窗口已成为明确瓶颈的场景。核心是选择能让主要请求单分片完成且分布均匀的分片键，同时设计路由、扩容、数据迁移、全局 ID 和跨分片查询方案。 它显著增加研发和运维复杂度，不应只因数据“可能变多”提前引入。

容量有了以后，再把入口、核心处理和数据落点串起来。沿着「估算单库容量上限 → 选择分片键与路由 → 执行单片读写 → 处理跨片查询事务 → 扩容迁移并核对」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 估算单库容量上限 分片前先证明单机在数据量、写吞吐或维护窗口上达到真实瓶颈，避免过早引入分布式复杂度。 选择分片键与路由 分片键决定流量与数据分布，应兼顾高频查询路由、热点和未来迁移；低基数字段通常不适合。 ShardingSphere route context：路由单元与广播 SQL。 informationschema.tables：各分片行数/体积偏斜。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

关键参数要从峰值流量和资源上限反推。回放用户侧与商家侧 Top 查询，统计单片/跨片比例；制造超级用户验证热点和扩容迁移。

正常链路之外，还要设计失败补偿和可验证的恢复流程。订单以 userid 分片满足用户侧查询，却忽略商家按店铺和时间查询。请求广播所有分片后容量随分片数恶化。增加面向商家的异构索引表或事件驱动查询库，比给每个请求并行扫全库更可控。 分片键形成超级热点：分片数据与 QPS 偏斜：跨片读建异构索引。 全局唯一约束无法由单片保证：跨片请求比例：热点租户单独路由。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「跨片请求」为主基线，记录值应满足「核心路径<5%示例」；同时保存 分片数据与 QPS 偏斜、跨片请求比例，使后续变化能够回到同一时间轴比较。

最后再讲扩容、成本和方案边界。方案：更适合的场景：主要收益：代价与边界。 垂直拆分：业务域边界清晰、单表未超限：隔离依赖与团队：跨域事务增加。 水平分片：单表数据或写吞吐超限：容量近似水平扩展：跨片查询、事务和扩容复杂。 异构查询存储：多种访问路径冲突：按查询模型优化：需要同步、延迟和对账。 选型至少带上 数据规模、选择性、读写比、事务长度和峰值并发，并用上面的量化基线验证；未知数据应明确为待测假设。