分表后JOIN无法跨物理表执行，因单机数据库不支持跨分片关联；需业务层路由、中间件重写或字段冗余解决。
分表后 JOIN 无法跨物理表执行
MySQL、PostgreSQL 等单机数据库原生不支持跨分表（尤其是跨库）的 JOIN。比如用户表按 user_id % 4 拆成 users_0 到 users_3，订单表也分表，想查“某用户最近 3 笔订单”时，SELECT ... FROM users_0 JOIN orders_2 ON ... 这类写法会报错或返回空——因为优化器根本不知道这些表逻辑上属于同一张大表。
常见错误现象：Table 'db.orders_2' doesn't exist（连库名都对不上），或查询只跑在单个分片上导致数据不全。
实操建议：
- 业务层先查出用户所在分片（如
user_id % 4 = 1 → users_1），再拼接对应订单分片（如orders_1），手动做两次查询 + 内存合并 - 用中间件（如
ShardingSphere、MyCat）代理 SQL，它能重写JOIN为多条单分片查询并归并结果 - 避免跨分片
JOIN，把高频关联字段冗余进主表（如订单表里存user_name），用空间换简单性
GROUP BY 和 ORDER BY 必须带分片键
分表后，聚合和排序操作若不包含分片键（如 user_id），数据库就无法确定该去哪个分片查。例如 SELECT city, COUNT(*) FROM users GROUP BY city，每个分片只存部分用户，直接执行会得到各分片局部结果，而非全局统计。
实操建议：
- 强制在
WHERE条件中带上分片键，让查询路由到唯一分片（如WHERE user_id = 12345），此时GROUP BY才安全 - 全局聚合必须由应用层收齐所有分片结果后再计算（如用
UNION ALL拉取 4 个分片的GROUP BY city结果，再用代码累加） -
ORDER BY create_time DESC LIMIT 10这类分页，得先从每个分片取前 10 条，再内存排序取 Top10——否则可能漏掉第 2 分片里的第 1 名
分页查询 LIMIT offset, size 性能断崖式下降
分表后，LIMIT 10000, 20 这种深分页没法下推到单个分片执行。中间件或应用需先从每个分片拉取至少 offset + size 行（比如 4 个分片就要拉 4 × 10020 = 40080 行），再合并、跳过前 10000 行——数据量越大越慢。
实操建议：
- 改用基于游标的分页：记录上一页最后一条的
id或create_time，下一页查WHERE id > last_id ORDER BY id LIMIT 20 - 禁止前端传任意
offset，后端校验最大允许值（如offset ），超限走游标方案 - 如果必须用偏移量，确保
WHERE条件已过滤到单一分片，避免跨分片拉全量
唯一性约束和自增主键失效
分表后，AUTO_INCREMENT 在每个子表独立计数，users_0 和 users_1 都可能有 id = 1；UNIQUE KEY 也只在本表生效，无法保证全局唯一（比如两个分片同时插入同名用户）。
实操建议：
- 放弃数据库自增，改用分布式 ID（如
Twitter Snowflake、Redis INCR、UUID）生成全局唯一主键 - 业务层做唯一性校验：插入前先查所有相关分片（或查一致性哈希映射的单一分片），但要注意并发竞争
- 关键字段（如
email）的唯一性，靠应用+缓存（如SETNX）+ 数据库联合约束兜底，不能只信单表索引
分表不是加个路由规则就完事——它把原本由数据库隐式承担的语义（关联、聚合、排序、唯一性）显式甩给了业务代码或中间件。最容易被忽略的是那些“看起来应该能跑”的 SQL，比如没带分片键的 GROUP BY 或跨分片 JOIN，它们在测试环境可能因数据少而蒙混过关，上线后突然查不出数据或慢到超时。
