兄弟姐妹们好啊！我是老王，干了快15年的数据库架构了，从Oracle到MySQL，从单机到集群，踩过的坑比写过的代码都多（笑）。今天跟大家唠唠我对分库分表和NewSQL的一些肺腑之言，不装逼，不吹牛，就是跟哥们儿喝啤酒时的那种闲聊。
别笑，我曾经也是分库分表受害者
先说个笑话，话说有个程序员，梦里被一堆分库分表的SQL路由规则追着打...那人就是我，哈哈！
2018年，我在某电商负责订单系统重构，当时日订单量暴涨，单表撑不住了。领导拍脑袋：分库分表！结果我们仨人熬了一周的夜，把代码改得像锅粥。上线那天，我俩战战兢兢，结果特么第一个小时就出事故了 —— 有些订单路由到了错误的库！
那场景，我现在想起来还后背发凉...老板站我旁边，运营MM疯狂催单，客服电话被打爆...我只能一边擦汗一边手动修数据。那一刻，我对分库分表的恨真是入骨啊！
两种方案，一眼辨真假
放张图，一目了然：
左边这种，就是我们传统艺能：分库分表。说白了就是在应用层塞个中间件（MyCat啊、Sharding-Sphere啊这些），底下连一堆MySQL。前几年这玩意简直火得不行，我参加的每个技术群都有人在讨论。
右边的NewSQL，就是近些年的新贵了，比如TiDB、OceanBase这些，整个就是一套全新的数据库系统，从零设计的分布式架构。
表面上看，NewSQL高大上啊，但实际用起来...emmm，且听我慢慢道来。
分布式事务：这个真没你想的那么美
各位老铁，有多少人真的用过分布式事务的？我敢说99%的项目用的都是悲观锁+重试，或者就是最终一致性。
记得去年我朋友小张（某互联网大厂P8）他们团队引入了某NewSQL数据库（给厂商面子，就不点名了），号称完美支持分布式事务。结果一上线，交易链路平均RT从40ms飙到了120ms！老大差点炸了，连夜回滚。
后来我们一分析，原来是大部分交易场景下，用户、账户、订单这些数据被分到了不同的分片，导致简单交易变成了分布式事务。这性能，怎么能接受？
我直接说：分布式事务这玩意，能不用就别用！
CAP理论不是吹的，就算Google爸爸的Spanner也只是靠原子钟+私有网络硬堆出来的"伪CA"。现实世界哪有这条件？
我们最后的解决方案是啥？柔性事务 + 消息队列。简单明了，性能还好。
异地多活：吹牛谁不会啊
去年我参加某数据库厂商的技术沙龙，他们吹得那叫一个天花乱坠："我们的数据库支持真正的异地多活，跨地域零延迟！"
我当场就想笑，这不是把程序员当傻子忽悠吗？除非他们解决了光速限制这个物理学难题...
实话实说，我干过两地三中心项目。北京到上海的专线网络，延迟最低也有30+ms。如果每个事务都要两地多个节点确认，这延迟直接就起飞了啊！
我一朋友在某支付平台，他们的方案是这样的：
- 核心交易记录异步复制到异地
- 部分热点数据双向实时同步
- 灾备切换时，有个"同步追平"的过程，期间部分功能降级
这才是靠谱的工程方案！那种号称数据库层面就能解决异地多活的，要么是不懂业务，要么就是...你懂的。
那自动分片是不是真香？
必须承认，NewSQL在自动分片这块确实甩分库分表几条街。
想当年，我在某互联网金融公司做分库分表设计，为了确定分片键，开了8次设计评审会！最后选了用户ID作为分片键，结果第一年还不错，第二年业务一变，发现很多查询需要跨库，性能直接拉垮...
NewSQL确实省心，它会自动分片、自动平衡、自动迁移，DBA省事多了。BUT，它的通用分片策略未必适合你的业务模型。
我一哥们儿用了某NewSQL后发现，他们的交易系统中，用户和账户天然一起访问的数据被拆到不同分片上，结果简单交易都变成了分布式查询，响应时间直接翻倍...
所以，技术选型这事，还得看场景啊！
真实案例：我帮某电商选型的经历
去年有个做母婴电商的创业公司找我做顾问，纠结是用分库分表还是NewSQL。当时他们的情况是：
- 用户量300万左右，每日订单5万单
- 技术团队就10来个人，没有专职DBA
- 之前都是用的MySQL单库
- 预计未来两年用户量翻倍
我给他们的建议超级简单：先别折腾，MySQL单库+优化索引+读写分离能扛一年没问题。
结果他们CEO不干，非要做"技术前瞻性规划"。好吧，那我就给他们算了笔账：
方案A：ShardingSphere + MySQL
- 成本：4台服务器，约25万
- 开发量：需要改造的表不多，约3周时间
- 维护：他们团队有MySQL基础，上手快
- 风险：分片策略定好了，短期内问题不大
方案B：某NewSQL产品
- 成本：最少6台高配服务器，再加上商业版license，接近100万
- 开发量：SQL兼容性问题，约1个月
- 维护：需要从头学习一套新技术栈
- 风险：新技术稳定性待验证，团队缺乏相关经验
最后CEO叹了口气："老王，就按你说的方案A来吧，我们现在经不起折腾。"
半年后他们来找我喝酒，告诉我系统运行得挺好，那个分库分表方案足够他们用两年了。
选型建议：对号入座，别硬套
做了这么多年架构，我最大的体会就是：别迷信新技术，更别被PPT忽悠。
我这儿有个傻瓜式选型指南，大家对号入座：
适合用分库分表的项目：
- 数据量大但增长可控，能预估未来几年的规模
- 业务模型相对简单，核心查询场景清晰
- 团队有MySQL或其他关系型数据库使用经验
- 预算有限，对成本敏感
- 系统偏OLTP，简单查询为主
- 能接受一定程度的应用改造
适合用NewSQL的项目：
- 数据爆炸式增长，规模难以预测
- 查询模式复杂多变，需要即席查询
- 团队有能力学习和驾驭新技术
- 预算充足，愿意投入更多基础设施
- OLTP和OLAP混合场景
- 希望尽可能减少应用层适配
说真的，大部分中小企业，用分库分表完全够了。别看那些互联网大厂都在用NewSQL，人家是真的数据量大到吓人，而且有专业团队运维。咱们普通企业，还是脚踏实地比较好。
总结：没有银弹，只有适合的选择
最后说句掏心窝子的话：分库分表和NewSQL各有各的坑，关键是你有没有能力踩过这些坑。
我见过用分库分表用到怀疑人生的团队，也见过引入NewSQL后天天被故障折磨的团队。技术没有绝对的好坏，只有合不合适。
记得我一个朋友（某知名外卖平台架构师）说过一句话："我宁可用熟悉的技术堆砌解决方案，也不要用陌生的'完美'技术。因为前者的坑我都知道在哪，后者的坑我可能都发现不了。"
这话我是服气的！
对了，说到坑，我还想起一个血泪史...算了，篇幅有限，下次再聊吧！各位铁子们，有问题欢迎评论区交流，我看到一定回！
最后的最后，分库分表会退出历史舞台吗？我觉得短期内不会。就像NoSQL当年也没让关系型数据库退场一样，不同技术总有各自的应用场景。
欢迎关注我的微信公众号「绘问」，更多技术干货等你来撩！
