“你做过分库分表吗？”
这是我在社招面试中，被问到次数最多的一句话之一。
一听到这个问题，我心里就会一紧：又来了，这道送命题。
有次面试官刚说完这句，我就顺势来了一句：“您是想听垂直分表还是水平分表？”
面试官笑了笑说：“那就从水平分表讲讲吧。”
于是，我的故事就这么开始了。
缘起：那张几乎让系统崩溃的订单表
几年前，我接手一个电商系统。
订单表 order_info 有将近 5000万行数据，每次查询都慢得要命。特别是那种根据用户ID查最近10条订单的接口，在高并发的促销活动中，简直是灾难级的存在。
日志刷得像弹幕，CPU飙升到90%，DBA一脸无奈地说：“小米，再不分表，这台数据库就要冒烟了。”
那一刻，我意识到：是时候出大招了——水平分表。
什么是水平分表？
简单来说，水平分表就是：
当一张表数据太多时，我们不去拆字段，而是“横着切”。
比如原来有一张大表：order_info
我们可以根据某个维度（比如用户ID、订单ID、时间），拆成多张：
每张表的结构完全相同，只是数据不同。
就像把一个超大的文件夹，拆成多个小文件夹，每个文件夹里只放部分文件，这样查起来快得多。
水平分表的几种常见策略
做分表，最关键的问题是：怎么分？
这一步决定了你后续是“顺风顺水”，还是“痛不欲生”。我在项目中踩过不少坑，总结下来有三种主流方案：
1. 按范围（Range）分表
比如：
- 2023年数据放 order_info_2023
- 2024年数据放 order_info_2024
优点：
- 查询某一时间段的数据非常快。
- 数据归档方便。
缺点：
- 热点数据集中在最新表，容易出现单表压力。
- 需要定期建新表，否则新的一年没表可写。
2. 按哈希（Hash）分表
比如用 user_id % 16 决定分到哪个表：
优点：
- 数据分布相对均匀。
- 并发高时能显著提升性能。
缺点：
- 不方便做跨分片统计。
- 分表数量固定，后期扩容比较麻烦。
3. 按业务维度（如地区、商户等）分表
例如：
- 华北区：order_info_north
- 华南区：order_info_south
优点：
- 逻辑清晰，方便独立维护。
缺点：
- 不同区域用户分布不均时，容易出现“冷热表”。
水平分表的难点：不止是“拆表”那么简单
很多人以为水平分表就只是建几张表，分几条数据。其实，真上生产你会发现，最麻烦的是后续问题：
1. 跨表查询
比如：
老板想查“近一年所有订单总额”，可你订单分散在16张表里——咋办？
解决办法：
- 写程序逻辑循环查询再合并结果；
- 或者用中间件（如 ShardingSphere、MyCat）来帮你分片聚合。
2. 自增主键不再唯一
原来用 AUTO_INCREMENT 一路走天下，结果分成16张表后，各自自增，冲突了。
解决办法：
- 用 雪花算法（Snowflake） 、UUID、自定义发号器；
- 或者用分布式ID服务（如 Leaf、TinyID）。
3. 事务问题
跨表、跨库后，事务就不再是单机的事了。这时候要用 分布式事务 或 最终一致性 模式。如果不控制好，可能出现“扣钱成功但没下单”的乌龙。
4. 数据迁移与扩容
最痛苦的环节来了——扩容。当你的16张表都快爆满时，想扩到32张？
不好意思，哈希算法全得改，数据要重分布，迁移代价巨大。所以，分表前一定要预留足够的分片空间！
那什么时候该用水平分表？
这是面试中很容易被反问的点。我一般这么回答：
“当单表数据量超过千万级、单表查询频繁且明显影响性能时，就可以考虑水平分表。”
具体来说，判断标准可以参考以下几个信号：
水平分表的最佳实践：从入门到进阶
下面是我个人总结的一套 “分表成长路径” ：
1、起步阶段：代码手动分表
- 最常见，也最灵活。通过代码控制表名。
- 适合中小型项目，但后期维护成本高。
2、进阶阶段：引入中间件
比如：
- Apache ShardingSphere
- MyCat
- Oceanus
中间件能自动路由SQL、合并结果、管理分片策略。这时开发只管写SQL，不用关心底层有多少表。
3、成熟阶段：配合分库分表、读写分离
分表只是开始。真正的架构优化，还包括：
- 分库：不同业务拆不同数据库；
- 读写分离：主库写，从库读；
- 缓存：用Redis做热点数据加速。
当你把这些配合起来，就能撑住双十一的洪峰流量了。
面试官最喜欢问的那几个“陷阱问题”
如果你正在准备面试，一定要注意以下几个点：
问题1：水平分表后怎么做分页查询？
用全局排序字段（如创建时间或雪花ID），然后程序聚合分页。
问题2：分表后如何保证唯一约束？
通过全局ID生成器或唯一索引服务统一管理。
问题3：分表后数据统计怎么办？
通过异步统计、定时任务、或数据仓库做汇总。
面试官问这些不是为了难你，而是想看你是否真的考虑过线上问题。
结语：分表不是万能药，合理才是关键
说实话，水平分表这件事，就像减肥。开始的时候很爽，性能嗖嗖提升；但后期维护、迁移、扩容的时候，你会哭着回忆从前的简单生活。
所以我常跟团队说：
“能不分就不分，能靠索引优化、缓存解决的，就别轻易动分表。”
有时候，一个合适的索引、一层缓存、或一个中间件配置，都比你动刀分表来得划算。
写到这儿，我回想起当年第一次上线分表方案那晚，凌晨两点，测试环境跑通后，我们几个人端着咖啡举杯庆祝。
那一刻我突然明白：
所谓 “架构师的浪漫” ，大概就是能让系统稳定地跑下去吧。
总结一句话：
水平分表，是一把双刃剑。它能让性能飞升，也可能让你后悔。想用好它，先搞懂业务，再规划架构。
我是小米，一个喜欢分享技术的31岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号“软件求生”，获取更多技术干货！
