和钱没关系，关键业务数据到1亿条以上，请几个高端dba都请不起，这个公司可以关门了，说明做的就不是赚钱的业务。不赚钱的业务建议还是不要再坚持了。

非关键业务数据（比如行为数据）或者表没到1亿行的，买个大点的mysql实例就得了。根本不需要分表。

sharding的问题是分表分的太傻了，sharding分表分完了之后，结果就是除了用了sharding的本微服务以外，其他人都没法碰这个表了（比如ETL去数据湖等等），然后sharding本身也容易出bug和性能问题(程序员不靠谱得时候).我以前碰到用sharding得，后来渐渐就都废了。假装没用
【 在 wudashu 的大作中提到: 】
: 这方案需要高端的数据库和高端的dba，都比较贵而且出问题的时候很难找到有经验的人来处理。
: 实际生产中，MySQL分库分表更实惠一些。业务侧自己定分库分表规则，加个路由映射，只用开发一次，工作量有限。而dba只管维护普通的MySQL。
: 发自「今日水木 on M2011K2C」
--
修改:Xjt FROM 211.144.19.*
FROM 211.144.19.*

用分布式数据库，不是钱的问题，是找不到人。不仅dba不好找，开发也不好找。更实际的是，如果某一天出线上问题，到底是开发的问题还是数据库的问题可能都要花不少时间定位，到时候扯起皮来线上都没人修。

另外MySQL现在很强，实际线上用过单表五亿行，日增量数百万的MySQL，性能很稳定。这也就导致线上真的需要分表的场景很少，只有当这种场景积累到一定量级的时候，换分布式数据库的收益才会明显大于分库分表，这种时候才值得换。

(可以参考，国内的各大互联网公司的业务基本都是MySQL分库分表，很少业务上分布式数据库)

【 在 Xjt 的大作中提到: 】
:  
: 和钱没关系，关键业务数据到1亿条以上，请几个高端dba都请不起，这个公司可以关门了，说明做的就不是赚钱的业务。不赚钱的业务建议还是不要再坚持了。  
:
: 非关键业务数据（比如行为数据）或者表没到1亿行的，买个大点的mysql实例就得了。根本不需要分表。  
:
: sharding
: ..................

发自「今日水木 on M2011K2C」
--
FROM 114.254.2.*

这不用太复杂，需要分库分表的场景很少。

如果业务小，让业务方自己写分库分表代码(比如直接在代码里指定目标库表)，多不了多少工作量，质量由业务自己负责。

如果业务够大，需要分库分表的场景够多，招个人维护一套db的工具，让他负责质量。
【 在 oldwatch 的大作中提到: 】
:  
: 然后压力全部压在某个来路不明无人维护的路由中间件上  
: --  
: 我明白，”罗拉娜喃喃道，史东被杀的景象和龙的尖叫声又鲜活地混杂在一起.  
: 别感到羞傀，泰斯。要感激上天，你还可以对死去的敌人感到同情。只要我们变得冷血，  
: 甚至是对我们的敌人，那就是我们输掉这场战争的时候
: ..................

发自「今日水木 on M2011K2C」
--
FROM 114.254.2.*

另外你说的其他人不能用的问题，一般的解法有:
1. 数据库binlog同步到hive，合成一张离线表
2. 数据库binlog同步到es，按天分索引，可以检索
3. 数据库binlog同步到MySQL，按天分表，可以提供天维度的实时MySQL查询

这些方案实施起来都比较简单可靠。
【 在 kangqi 的大作中提到: 】
: 大神们，你们都用过哪些分库分表框架，支持了多大数据量  
: --  
:

发自「今日水木 on M2011K2C」
--
FROM 114.254.2.*

数据大到需要多实例就另说了
【 在 wudashu (wudashu) 的大作中提到: 】
: 分区只能帮忙优化索引（我更倾向于认为分区是内置的单实例分表功能），不能水平扩展，成倍提升性能。
--
FROM 183.6.114.*