后端工程师 | 分库分表策略之PG扩展

后端工程师 | 分库分表策略之PG扩展
这事儿我可真踩过坑，分库分表不是你想分就能分的事儿，它得看你的业务耦合度和数据访问模式，别傻乎乎地以为分了就能解决所有问题。尤其是PostgreSQL这种不支持原生分库分表的数据库，你得自己琢磨扩展方案，不然分完表数据还乱，查询还慢，最后连你都怀疑是不是自己瞎折腾。我见过几个项目分库分表之后，跨库查询又得用JOIN，又得走分布式事务，结果性能还不如单库。关键是你得知道什么时候该分，分哪一张表，怎么分，这玩意儿没有标准答案，得看你具体业务场景。

分库分表最怕的就是业务耦合太强，数据间频繁关联。比如我之前做用户订单系统，订单表和用户表分开了，结果每次查订单还得捎带上用户信息，JOIN跨库又得走远程查询，性能直接炸了。后来我改用物化视图，把用户信息同步到订单库，虽然有点数据延迟，但查询速度上来了。你得先评估业务，别光看表行数多就分，得看业务逻辑是否需要跨表操作。

分表的话，最常用的还是按时间分，或者按业务ID分。我之前做日志系统，按时间分表，用日期作为后缀，比如log_20260701。这样可以平滑数据增长，还能按天清理。但你得注意，查询条件里有时间字段的话，索引还得跟着变，否则查询效率还得往下掉。还有按业务ID分表，比如用户ID模100分到100个表，但得确保业务ID是连续的，否则容易出现数据倾斜，某些表数据多，某些表数据少，搞不好还会卡死。

分库分表别光盯着数据量，得看查询频率。我之前有个项目，用户表分库后，频繁查手机号和昵称，结果一次查询要连两个库，性能直接掉地上。后来我冒险把用户表和订单表放在一起，虽然数据量大了，但查询负担小了。这个决策标准就是，如果某个表的数据访问频率特别高，而且和其他表有频繁交互，就别分。分完你得花更多力气维护JOIN逻辑。

PG扩展这块，我用过的最多是pg_shard，但别指望它能自动搞定。你得自己写SQL，自己加路由逻辑，光靠它挺不顶用的。有一次我一个同事直接用了pg_shard，结果数据分布不均，查询总得在多个分片里跑，效率全没了。后来我改成用一个中间路由层，把查询发到对应分片，虽然麻烦，但控制住了。记住，PG扩展是工具，不是万能药，得你自己搭逻辑。

你得知道分表分库之后，备份和恢复就变得特别麻烦。我之前有个项目分表后，直接用pg_dump备份所有表，结果一张表要跑几个小时，线上连不上。后来改用逻辑复制，每个分表单独开槽，虽然复杂，但能保持一致性。你得评估备份频率和数据量，别光图省事，结果备份又慢又容易出错。这个细节我印象中是某次生产事故后才学会的。