关于 mysql 分表存储的问题

[baoruizhe]

请教大家一下一个关于 mysql 存储的问题： 项目背景：springboot + mybatis plus + mysql(单机) +redis， 现在有一个业务的表数据持续增长，目前统计该表已经有 3000W 左右的数据了(这些数据可能客户都会用到,所以不能删除以前的)，每天有 50 到 100w 左右，预计未来会更多，可能很快就会达到瓶颈，如果想到优化，大家可能第一时间想到的是分库分表，这个思路也没毛病，要用到分库分表就要考虑使用中间件，我目前了解到的比较合适的有 Sharding-Sphere, 我想的是主要解决容量存储问题，所以针对于这张表采用分表的方案, sys_table_1,sys_table_2...，然后按照主键策略，奇数存第一张表，偶数第二张，但是最大的问题就是采用了分库分表后通过主键查询 更新没问题，但是涉及到其他条件查询好像就力不从心了，想请教下大家在工作中有遇到解决 mysql 单表数据量过大的实际方案吗？ ps:刚才写的时候想到一个分表的复杂条件查询解决方案:用 es 同步 mysql，复查查询走 es，取到主键，再去数据库查询

[baoruizhe]

顶顶顶，大家可以一起讨论学习下

[cheng6563]

Sharding 可以非非主键查询

[baoruizhe]

@cheng6563 官方说的暂不支持勒

[gantleman]

查询的部分上 lucene 或 spark 。

[Jooooooooo]

分表你要解决的问题至少有

1. 分表是否真的解决问题. 会不会出现分表之后依然有大表(或者热点表, 热点行等等)的问题. 分表之后能抗多久以后的业务? 至少是一到两年不用再动才有价值.

2. 用什么维度去分表, 分表之后所有的查询最好是集中在一个表上, 跨表查询会非常麻烦. 当前维度能不能适应之后业务的发展? 会不会出现新业务分表无法支撑又得重做一遍. (用 ES 查询的方案调研清楚了吗, 能否满足要求)

3. 现在是单表, 无缝过渡到分表的方案是怎么样的? 期间风险怎么降低和规避. (比如数据一致性, 业务正确性等等)

应该还有许多, 做过的人可以再补充.

[vchat]

1. 分库和分表是解决水平扩展的问题；
2. es 是解决复杂查询的问题；
3. 历史数据量多， 需要考虑这些历史数据全部范围的数据都需要实时查询吗？

[littlewing]

分库分表是用来解决 tps 过大的问题的
你这个是数据量大，需要做冷热数据分离