随着公司业务发展，目前需要考虑数据扩容这方面业务，
最近在看mysql的分库分表，感觉操作很复杂，相比之下 TiDB 好像更简单一些？
咨询了一些大厂同学，他们目前核心业务还是在使用分库分表的方式，
为什么大公司核心库不用 TiDB 这种分布式数据库呢。
现在用分库分表的已经越来越少了吧，你看现在国产的数据库都不走这一套了，oceanbase也是
是的，但是咨询了一些大厂同学，他们目前核心业务还是在使用分库分表的方式，TiDB 这么香为啥不切呢
腾讯的tdsql也是分库分表的分布式把
腾讯不太清楚，了解过 京东和 58 同城的交易是分库分表的策略
分库分表产品化打包卖，也是可以的
既然是核心服务，那必然是写了好几年了，运行了很多很多年的服务，你敢动吗？tidb几年前还不是那么有名。
再过个五年八年的，估计分库分表就差不多被替掉了。
这个我熟
1、一方面是增加运维工作量，体现价值；
2、另一方面是第三方供应商为了卖机器，瞎搞
1 个赞
分库分表都玩了好久了，替换需要人力太麻烦，互联网业务场景简单，分库分表也比较适合这个场景，也好体现运维的“价值”。
我觉得主要是在大厂这两个字上吧，像小厂，一个人一句话就可以决定使用分布式，不用分库分表。
分布式了，简单
趋势就是分布式，分库分表是过去式了
分布式的多。
也用过分布式的，里面再分库分表，单表有行数限制
按你要这样说的话，很多系统核心都还在用oracle，虽然去IOE喊了这么多年，oracle还是有很多人无法舍弃，这个很多是历史原因导致的，我只能说你现在新上业务，你去推销原来那套分库分表，难度非常高，很少有人会被忽悠了。。。
1 个赞
重点行业都提前多年有自己的选型，追求稳定成熟，循序渐进，tidb才出来多久，渗透率太低，关键懂得运维人员也少，需要时间和产品成熟度积累。 
这都是历史包袱啊~我们也有，扔都扔不掉~
TiDB 的 latency 和长尾问题在核心交易场景目前是技术上的硬伤
切换是需要代价的，特别是本来分表分库就是对代码有侵入的。好不容易上线折腾稳定了，现在一句话，改分布式，代码是不可能不改的吧。这个改造成本就是最大的阻碍。哪怕性能方面的担忧，其实归根到底也是成本。
我看现在的趋势像是，新系统越来越多的是有着raft，paxos这类分布式协议保证的DBMS。老的架构方式，无论是分表分库还是主从同步，这都被慢慢抛弃。
1 个赞
说的很对，不是不想换，只是目前换的人力成本太大，这个是一个循序渐进的过程，可以关注下现在重构应用或者新建应用是使用分布式数据还是分库分表的多，而不是关注存量的，存量很多是历史遗留和成本的问题。
是的，大部分切换并不是一句话就能解决的，也并不是说数据库换了就可以，还是有诸多的问题，比如应用端代码改造、上下游切换这些问题就可以够折腾了。不过这些问题也能解决，但是最终还是聚焦到要花多少成本，毕竟是真金白银的投入，而不是纸上谈兵。
1 个赞