垂直分表

垂直分表在日常开发和设计中比较常见，通俗的说法叫做”大表拆小表”，拆分是基于关系型数据库中的”列”（字段）进行的。通常情况，某个表中的字段比较多，可以新建立一张”扩展表”，将不经常使用或者长度较大的字段拆分出去放到”扩展表”中。在字段很多的情况下，拆分开确实更便于开发和维护（笔者曾见过某个遗留系统中，一个大表中包含100多列的）。某种意义上也能避免”跨页”的问题（MySQL、MSSQL底层都是通过”数据页”来存储的，”跨页”问题可能会造成额外的性能开销，拆分字段的操作建议在数据库设计阶段就做好。如果是在发展过程中拆分，则需要改写以前的查询语句，会额外带来一定的成本和风险，建议谨慎。

垂直分库

垂直分库在”微服务”盛行的今天已经非常普及了。基本的思路就是按照业务模块来划分出不同的数据库，而不是像早期一样将所有的数据表都放到同一个数据库中。系统层面的”服务化”拆分操作，能够解决业务系统层面的耦合和性能瓶颈，有利于系统的扩展维护。而数据库层面的拆分，道理也是相通的。与服务的”治理”和”降级”机制类似，我们也能对不同业务类型的数据进行”分级”管理、维护、监控、扩展等。

众所周知，数据库往往最容易成为应用系统的瓶颈，而数据库本身属于”有状态”的，相对于Web和应用服务器来讲，是比较难实现”横向扩展”的。数据库的连接资源比较宝贵且单机处理能力也有限，在高并发场景下，垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈，是大型分布式系统中优化数据库架构的重要手段。

水平分表

水平分表也称为横向分表，比较容易理解，就是将表中不同的数据行按照一定规律分布到不同的数据库表中（这些表保存在同一个数据库中），这样来降低单表数据量，优化查询性能。最常见的方式就是通过主键或者时间等字段进行Hash和取模后拆分。水平分表，能够降低单表的数据量，一定程度上可以缓解查询性能瓶颈。但本质上这些表还保存在同一个库中，所以库级别还是会有IO瓶颈。所以，一般不建议采用这种做法。

水平分库

水平分库分表与上面讲到的水平分表的思想相同，唯一不同的就是将这些拆分出来的表保存在不同的数据中。这也是很多大型互联网公司所选择的做法。某种意义上来讲，有些系统中使用的”冷热数据分离”（将一些使用较少的历史数据迁移到其他的数据库中。而在业务功能上，通常默认只提供热点数据的查询），也是类似的实践。在高并发和海量数据的场景下，分库分表能够有效缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源的瓶颈。当然，投入的硬件成本也会更高。同时，这也会带来一些复杂的技术问题和挑战（例如：跨分片的复杂查询，跨分片事务等）。

注意

很多人并没有从根本上搞清楚为什么要拆分，也没有掌握拆分的原则和技巧，只是一味的模仿大厂的做法。导致拆分后遇到很多问题（例如：跨库join，分布式事务等）。

四种拆分形态与”别盲目模仿大厂”的告诫都到位，缺的是决策链：拆之前做什么（优化顺序）、拆的维度怎么选（分片键）、拆的规模怎么定（分片数）、用什么工具落地。本文补全成可执行的分库分表设计指南。

拆之前的优化顺序（先穷尽单机）

  1. 索引与 SQL 优化（慢查询治理，收益最大成本最低）
  2. 缓存挡读（热点读离库）
  3. 读写分离（读扩展，主库减压）
  4. 归档与数据治理（历史数据迁走，热表瘦身）
  5. 字段/类型优化（大字段拆出=垂直分表先行）

以上用尽仍不达标才分片——分片是最后手段而非第一选择，因为它的代价（跨片查询/事务/扩容）是永久性的。

分片键（shard key）选择：设计的生死线

原则：

  • 高频查询维度：绝大多数查询带分片键（否则全片扫描=分片失败）
  • 数据均匀：哈希分布防热点；但哈希牺牲范围查询（时间序扫描跨全片）
  • 与业务主维度一致：订单按 user_id 分（用户查自己的订单单片命中），而非 order_id（用户维度查询全片扫）
  • 避免二次拆分痛苦：分片键一旦选定几乎不可改（改=全量迁移）

经典组合：user_id 哈希分库 + 时间范围分表（库内表按时间滚，兼顾用户维度单片与归档便利）；基因法（把分片位编入订单号）解决”按订单号查也要单片命中”。

分片数与容量规划

  • 单片数据量目标：单表千万行内 / 单库 TB 级内（经验值，按行宽与查询模式调整）
  • 分片数=预估 3-5 年数据量 ÷ 单片容量，一次定够或预留翻倍路径（扩容迁移是分片系统最痛的操作）
  • 分片数与机器数解耦：一机多片，扩容=搬片而非重新哈希（一致性哈希/号段映射表）

落地工具谱系

方案 形态 特点
ShardingSphere-JDBC 客户端分片（无中间件） 无额外部署、语言绑定 Java、性能好
ShardingSphere-Proxy / MyCat 代理层分片 语言无关、多一跳延迟、独立运维
自研路由层 DAO 层封装 可控最强、成本最高
NewSQL（TiDB/CockroachDB） 不分片（分布式数据库透明扩展） 把分片复杂度交给数据库，运维简化、成本与兼容性需评估

NewSQL 是”要不要自己分片”的新时代选项：业务 SQL 复杂度高的团队，TiDB 类透明分布式可能比自研分片总成本更低。

拆分后的设计约束（写进团队规范）

  • 禁跨片 join（应用层拼装/冗余宽表/ES 异构索引替代）
  • 禁跨片事务（本地事务+最终一致/Seata 按需）
  • 全局唯一 ID 替代自增主键（雪花/号段）
  • 分页深翻改游标/ES 承接（跨片 offset 是灾难）
  • 唯一约束降级为”片内唯一+全局去重表补偿”

决策 checklist

  • 单机优化五步走完了吗（有压测数据）？
  • 分片键覆盖了多少比例的查询（<90% 慎重）？
  • 分片数按几年规划？扩容路径是什么？
  • 跨片查询/事务/分页的替代方案定了吗？
  • 团队有分片系统的运维能力吗（监控分片均衡、迁移演练）？

分库分表的本质是把单机能力边界问题转化为路由与一致性问题：垂直拆解决”宽与职责”，水平拆解决”量与吞吐”；而分片键、分片数、工具选型三个决策定了系统未来五年的天花板与痛苦指数——先穷尽单机优化、再按 checklist 决策，才不会把”模仿大厂”变成”继承大厂的痛”。