SQL 分表后查询为何变复杂？

分表后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，它们在测试环境可能因数据少而蒙混过关，上线后突然查不出数据或慢到超时。