数据量大，有比分库分表更好的解决方法吗

[cccjh]

目前项目上有个表的数据每月增长 100w 条（实际 6,7,80w 吧），当前用的是 mysql，用的按月分表存储的。
有其他方便的替代方案吗？
目前有考虑的是用 tidb 存储
或者 es 做存储(先不讨论 es 不适合做主存储的问题，因为公司业务，而且公司以前就用 es 做主存储过)

[Octopvs]

才 100w 啊,看你怎么用这些数据了,一千万一个表我都觉得是正常的

[lavanil]

生产环境中 B+树的高度是 4 层就没有问题

[chencode]

我们有个日增 60W 条的单表，现在都十几亿了，只要索引建的好，sql 写的棒，速度还是杠杠的。
不过 tidb 确实不错。扩展性好。

[cccjh]

@Octopvs 是每月 100w，多几个月查询就特别卡了，这些数据经常会被查询统计的

[cccjh]

@chencode 是 mysql 吗？单表过亿还不卡，具体是多少耗时，我们项目需要查询至少在 1 秒内。

[lancelee01]

看 SQL 吧，如果你们的 SQL 查询的时间范围跨度太大，不管什么数据库，分不分表，都查的很慢，因为相当于全表扫描。

[lancelee01]

大数据量，总量都没上亿 [doge]

[luoqeng]

NewSQL 了解下

[encro]

统计，
那么不是分库分表的问题了。
是需要加统计表。

我们阿里云 2 核 8G,记录大概 3 亿条，200 多 G，通常页面请求都在 0.1 秒内出来。

你得先学会分析慢在哪里。


https://c4ys.com/archives/2349 Mysql 必知必会 -》 Mysql 性能工具

通常来说统计都是很慢的，需要自己加统计表。

比如我们项目有几百个店铺，每天一个店铺几万条数据，需要统计每个店铺和所有店铺的多项指标，那么我可以加这样几个表

stat_total_per_day
stat_store_per_day
stat_total_per_week
stat_store_per_week
stat_total_per_month
stat_store_per_month

stat_total_per_day 例子:
date,key, value
对 key,date 建立唯一组合索引。

stat_store_per_day 例子：
date,store_id,key,value
对 store_id,key,date 建立唯一组合索引

[teddy2725]

每个月 100w 我觉得不算多，不需要分库分表。在线业务和离线分析不用放在一个库里。

[rapperx2]

这数据量，用你目前的方案完全够了吧

[rapperx2]

要么就了解下 OLAP 数据库，ClickHouse

[Leigg]

一年才一千万，mysql 根据表结构情况，单表撑得住千万到亿级，pg 应该更优秀才对，你目前月表方案完全够用，如果想统计，可以用 clickhouse，但不是替换哈，是增加，ck 不支持更新删除。

[cco]

- -。你这量级 mysql 完全扛得住- -。

[chencode]

@cccjh 目前已经迁移 tidb 了，单表数据十亿级别，
试了一下，查询 5 个字段，使用一个时间范围过滤去查询，搜索 13w 条数据大概用时 4S，这里应该大部分时间用在传输上了。
使用两个字段搜索固定单条数据，时间在 1S 左右。