Sharding

分库分表

When to Invoke

单机归档/分区/索引之后，容量或写入仍明显不够；或已有分片要改。用户点名分库分表时也读本文件，但默认结论可以是「现在不上」。

When NOT

慢 SQL → mysql-index。表结构/归档/分区 → table-design。面试背「分库分表」不等于业务现在要做。

风险（面试考点）

拆了之后：跨库 join、分布式事务、扩容迁数、全局唯一 ID、分页排序都变难。选错分片键（按状态、按日期当唯一键）会导致热点或查一次扫全分片。

分区表 ≠ 分库分表。分区仍是一个 MySQL 实例。

适用场景

• 订单按 user_id 查询占 90%，单库写入顶不住
• 流水按 merchant_id 查询，单表归档后仍过大

方案选型（轻量优先）

升级触发（要能说出数字）：单表 > 千万且归档无效，或写入打满单实例磁盘/CPU，且查询有稳定等值键。

默认方案（真要拆时）

分片键 = 最常用等值查询的那个列，且写入分散：C 端订单用 user_id，B 端商户后台若也是主入口，考虑订单表冗余或映射表，不要幻想一个键同时完美服务两端。

shard = user_id % 16          # 简单取模，扩容要迁移
# 或一致性哈希：扩容迁移更少，运维更复杂

规则：

• 所有查询尽量带分片键
• 禁止跨分片 join；应用侧聚合或宽表
• ID 用雪花（distributed-id），按分片键路由不靠自增
• 跨分片分页：禁止简单 LIMIT 合成；用 ES/宽表/业务限制必须带 user_id
• 跨分片写：不要上 Seata 当默认，见 distributed-transaction

订单号可内嵌分片信息，便于客服按单号路由。

反例

错误：一上来 8 库 64 表，列表还要「全平台按时间排序」。 正确：这种查询形态不适合分片；先改查询或上检索。

错误：用 status 当分片键。 正确：状态基数低，热点严重，且状态会变（迁移噩梦）。

错误：把「加个联合索引」写进分片方案。 正确：回 mysql-index。

验证

• 主路径 SQL 都带分片键，能路由到单片。
• 扩容/迁移有演练，不是只写了算法。
• 不存在隐藏全分片扫描的管理接口打生产。

评审清单

• 是否其实只用索引/归档就够
• 分片键是等值高频列且不可变
• 跨片 join/排序有交代
• 没有和索引 skill 混写