分库分表,可能真的要退出历史舞台了
当前位置:点晴教程→知识管理交流
→『 技术文档交流 』
要是你做后端有点年头,大概都经历过那个疯狂搞分库分表的年代吧。那会儿,谁的系统里没个分库分表方案,简直都不好意思说自己是搞高并发的。但最近两年,这个话题开始变味了,越来越多团队在说:“我们可能不需要分库分表了。”今天就聊聊这事儿,为什么分库分表这套可能真的要退场了。 一、当年的“分库分表热”十年前左右,MySQL 还是单机王者,互联网公司疯狂增长,数据量动不动就几个亿。那时候数据库性能还没现在这么强,分表分库是唯一出路。 最常见的方案无非两种: 垂直拆分:不同业务用不同库,比如用户库、订单库、商品库。 水平拆分:同一张表数据太多,就按 user_id 或时间字段哈希到不同的库表里。 代码里一般会有个分片算法: 像这种逻辑看似简单,真落地的时候一堆问题:SQL 不好查、分页麻烦、跨表 join 要自己拼。后来大家干脆上了中间件,比如 ShardingSphere、Mycat、Cobar,全帮你搞定。但那时候谁都没想到——这玩意儿的复杂度,迟早要反噬。 二、分库分表的隐痛刚开始分得挺爽,数据库压力下来了,查询也快了。可系统一上量,坑就来了。 最典型的几个:
后来一些人想聪明点,搞“按时间滚动分表”,比如按月新建表: 听起来优雅,其实等你查个半年内订单,又要 union 全表。慢得你都能去冲杯咖啡。 三、为什么现在很多公司开始“反分库分表”这几年数据库技术的进步真不是闹着玩的。 一方面,硬件变便宜。现在随便一个云数据库实例,32 核 128G 内存,单库撑个十亿级数据根本不是问题。 另一方面,分布式数据库成熟了。像 TiDB、OceanBase、PolarDB 这种 HTAP 架构,底层自动分片、自动路由、自动事务一致性,开发几乎无感知。以前我们手搓的那些分库分表逻辑,人家底层都帮你干完了。 TiDB 的写法就和 MySQL 一样: 它内部会自己决定数据放哪台节点,SQL 一样能 join、分页、事务。对开发者来说,就是在用一个“大 MySQL”。 所以很多团队开始做架构回收,把原本拆散的分库分表,合回去一个分布式数据库集群。代码简单了,问题也少了。 四、还有个现实问题:成本和人力分库分表虽然性能能上去,但维护成本真的高。 每次加表、扩库、改字段,都得改路由规则;中间件升级要测一堆兼容性;出问题排查起来也麻烦,日志要在十几个库里翻。 最可怕的是——你项目人走了,新人接手的时候,看着几十个分表,只想辞职。 现在大家算账算明白了:与其省那点数据库压力,不如花钱上更强的实例、用分布式数据库。毕竟人的时间最贵。 五、那是不是以后都不用分库分表了?也不是。 分库分表依然有意义,只是它从“性能优化首选”变成了“最后的不得已手段”。 比如你做的是极端高并发的交易系统,单表每秒几万写入,那再牛的分布式数据库也顶不住,这时候还是得物理拆分。 或者业务天然隔离,比如全球多地域部署,不可能全写一个集群。 但对大多数中小团队来说,现在 MySQL + Redis + 分布式存储 + 消息队列,已经能撑到相当规模了,根本用不到分库分表那套复杂玩意儿。 六、写在最后我认识一个朋友,去年刚把系统从 ShardingSphere 迁回 TiDB。迁完之后一句话:“终于能好好写 SQL 了。” 这事其实挺有代表性的——过去我们为性能牺牲了开发体验,现在技术迭代让我们能两者兼得。 分库分表不是错,它只是那个时代的产物。就像当年的 CD、U 盘一样,完成了历史使命,也该退场了。 未来的方向是让数据层自动扩展,让开发者不必再关心“这一行数据该放哪张表”。真正的分布式系统,不该让人感受到“分布”这件事。 毕竟,技术的进步,本来就是让人少点痛苦,多点优雅。 -END- 阅读原文:原文链接 该文章在 2025/10/29 18:43:19 编辑过 |
关键字查询
相关文章
正在查询... |