分库分表搞了一年，我总结了七个「谁用谁倒霉」的坑
说出来你可能不信，我们团队搞分库分表，整整折腾了快一年。期间经历了两次上线回滚、三次数据迁移事故、无数次「为什么这条数据查不到了」的灵魂拷问。
这篇文章不发任何基础知识——什么是分库分表、为什么要做、用什么中间件，这些你随便搜一下就有。我只说那些书里不会写、教程不会提、等你踩到已经晚了的事情。
第一个坑：跨库查询，你以为能避免，其实绕不开
分库之前，你信誓旦旦：「以后所有查询都带分片键，绝不跨库！」
分库之后第一周，产品经理来了：「我想加一个全站搜索功能，能搜所有商品吗？」
你沉默了。
跨库查询是分库分表后躲不开的问题。不是因为你设计得不好，而是业务本身就有这个需求。常见方案：双写（数据延迟、存储翻倍）、ES/MongoDB（同步链路复杂）、打散查询再聚合（慢且分片多了直接超时）。没有完美方案，只有「你能接受哪个不完美」。
第二个坑：唯一ID的坑，比你想象的深
单机MySQL，自增ID用着多爽。分库分表之后，这玩意儿直接报废——多个库各自自增，ID必定冲突。
你以为搞个UUID就完事了？Too young。UUID作为主键，索引体积膨胀3倍，范围查询全部失效，存储还翻倍。
常见替代方案：雪花算法（Snowflake，依赖时钟回拨可能重复）、UUID v7（时间有序但对某些数据库索引不友好）、Leaf号段（需要独立发号器服务，单点问题）。最坑的是：你一旦选了某种ID方案，想换？数据迁移了解一下。
第三个坑：分布式事务，你迟早要还的债
单机数据库，ACID是你的朋友。分库之后，跨库事务就是你的债主，早晚得上门。
分布式事务方案：2PC（性能损耗大，coordinator挂了就是世纪大坑）、TCC（代码侵入性高）、本地消息表（最终一致性，实现相对简单）、Saga（适合长事务）。我的忠告是：尽量把业务设计成不需要跨库事务。如果实在绕不开，选本地消息表，成本最低。
第四个坑：分片键选错了，比不分还惨
选分片键这件事，选对了是天堂，选错了是地狱。而且这个错误不是立即显现的——它会像慢性毒药一样，在业务增长过程中慢慢发作。
典型错误：按用户ID分片，但某个大V用户数据量是普通用户的1000倍，这个分片成了热点，水平扩展效果约等于零。再比如按时间分片，但用户查询往往不以时间为条件——想查「这个用户的所有订单」，结果数据按时间打散在12个分片上，每个分片都要扫一遍。
选分片键之前，问自己三个问题：80%的查询条件都带这个键吗？这个键的数据分布均匀吗？业务增长后还会均匀吗？
第五个坑：数据迁移，是最容易被低估的环节
很多人以为分库分表最难的是改代码。错。最难的是数据迁移。
我们用的是「双写+数据校验」方案：阶段一，代码改好同时写新旧两个数据源；阶段二，跑数据迁移脚本同步历史数据；阶段三，数据校验；阶段四，灰度切读先切10%流量观察；阶段五，全量切读下掉旧数据源。
实际上每个阶段都是坑：双写阶段新旧数据格式可能不一致；数据校验本身在大数据量时就是性能杀手；灰度切读遇到bug要能秒级切回，必须有自动化开关。血的教训：数据迁移方案一定要在上线之前做完，并且做一次完整演练。
第六个坑：运维复杂度爆炸，你的人手够吗
分库之前，你对数据库的操作是一条命令。分库之后，你面对的是16个分片要逐个操作，还要确认每个分片执行成功没有、失败的要不要重试、成功的和失败的要记录、上线和回滚脚本是否是同一套。
配套运维工具必须到位：分片管理平台、统一的监控告警、自动化变更脚本、故障切换预案。如果没有这些配套，分库分表之后运维同学会天天想辞职。
第七个坑：你的业务，真的需要分库分表吗？
我见过太多团队，数据量还没到1000万就去搞分库分表，结果维护成本飙升，一堆跨库查询搞不定，最后还不如合回去。
在动手之前，先问自己：单机MySQL的容量上限摸到了吗？（通常单表超过5000万行要谨慎）慢查询优化做完了吗？读写分离试过了吗？缓存用够了吗？（热点数据走缓存，数据库压力能降90%）
分库分表是核武器，除非业务规模真的到了那个量级，否则不要过早优化。技术选型永远要匹配业务发展阶段，而不是为了炫技。
结语
分库分表这个话题，纸上谈兵容易，真正落地很难。我见过太多团队「高高兴兴设计方案，骂骂咧咧上线维护」。不是说分库分表不好，而是它带来的复杂度是全方位的：应用层、数据库层、运维层、监控层，每个环节都要跟上。
如果你正在考虑要不要做分库分表，我的建议是：先缓缓，看能不能通过其他手段解决问题。如果最终发现不得不做，那就做好心理准备——这是一场持久战，不是一个月能搞定的事情。
搞完分库分表之后，我最大的感悟是：有时候最土的方案，反而是最靠谱的。加机器、加缓存、优化索引——这些听起来不够酷的事情做好了，能让你省掉太多麻烦。
行了，今天的吐槽就到这里，我要去看我那个跑不动的单库了——毕竟，有时候不折腾，才是最好的折腾。
