SQL水平分表是将大表按行拆分为结构相同的小表以降低单表数据量，缓解性能问题；主要策略包括ID范围分表（适合自增ID、易归档但易热点）、时间分表（适配时序数据、冷热分离好但跨期查询复杂）和哈希分表（负载均衡好但不支持非分片键范围查询），落地需解决路由统一、全局ID、跨表聚合及扩容等关键问题。
SQL水平分表的核心，是把一张大表按行拆成多个结构相同的小表，让单表数据量降下来，从而缓解查询慢、锁竞争、索引深度过大等问题。它不改变字段结构，只分散数据行，适合单表超千万甚至亿级的场景。
按ID范围分表：适合有明显顺序特征的数据
比如订单表主键是自增ID，可按ID段切分：order_0001（1–100万）、order_0002（100万零1–200万）……这种策略逻辑简单，归档和删除历史数据方便，比如直接DROP掉order_2022的整张表。
- 适用场景：ID连续增长、业务写入相对均匀、查询常带ID区间条件（如“查ID在50万到80万之间的订单”）
- 注意点：容易产生热点——新订单总往最新表写，导致该表QPS高、磁盘IO集中；老表长期闲置，资源利用不均
- 建议搭配时间维度使用，例如“ID % 100 + 年份”组合，缓解单一维度倾斜
按时间分表：天然适配时序类业务
电商订单、日志、监控数据等，天然按天/月/年归档。可建表 order_202601、order_202602……查询某个月数据时，路由明确，无需扫描全量表。
- 优点：冷热分离清晰，历史表可设为只读或迁至低配存储；备份恢复粒度更细
- 缺点：跨月份查询（如“近90天订单汇总”）需应用层合并结果；月末/年初可能因批量导入造成单表瞬时压力
- 小技巧：用分区表（PARTITION BY RANGE (TO_DAYS(create_time))）替代手动建表，运维更轻量，但本质仍是逻辑分表
哈希分表：追求数据与负载均衡
对分片键（如user_id、order_no）做哈希再取模，决定写入哪张子表。例如 user_id % 16 → 写入 order_0000 到 order_0015 中的某一张。
- 优势：数据分布较均匀，读写压力天然打散，不易出现单表瓶颈
- 限制：无法支持非分片键的范围查询（如“查所有上海用户”若没存city字段在分片键里就难路由）；扩容时模数变化需迁移大量数据
- 进阶做法：用一致性哈希减少扩容迁移量，或结合虚拟节点提升均匀性
设计时必须考虑的关键细节
分表不是建几张新表就完事，真正落地要闭环处理几个硬性问题：
- 路由逻辑必须统一且稳定：应用层或中间件（如ShardingSphere）需根据分片键准确算出目标表名，不能靠人工拼接或配置错位
- 全局唯一ID不能依赖自增主键：每张子表独立自增会导致ID冲突，得用雪花算法、数据库号段、或UUID+时间戳组合生成
- 跨表聚合和JOIN基本不可行：MySQL原生不支持跨表关联，统计类需求需在应用层收拢多表结果，或引入ES、OLAP引擎辅助
- 务必预留扩容路径：比如初始16张表，未来要扩到64张，提前设计好ID哈希空间，避免全量重分
