mysql 一年新增 800 多万条数据，如果是单表的话请问服务器能支撑吗？各位有什么好的办法吗？

[sxinsuoyu20]

有个室温采集系统，一共 1686 个住户，每小时取一次数，供热季从 10 月份取到明年 4 月份，大约
1686*24*30*7=8,497,440 条数据，后期涉及到统计，分组排序等。
目前想到的办法是一年新建一张表，存储历史，然后做个配置表去管理查询哪张表。各位有在实际中遇到过相似问题的吗？有更好的办法吗？

[zdw406]

800w 数据量不算大
统计可以提前跑批，按需求设计专门存统计数据的表
一个主表可以存当前时间往前间隔固定时间（比如当前时间之前 1 年）的数据，历史表分表，这个数据量用不着分库

[molika]

docker 里面跑的 mysql 云虚拟机 一年跑了 4000 多 w 条数据 还会连表查询..目前没有任何压力

[jimrok]

800 万单表存储是没有问题，估计你也不开放查询给用户使用，这种数据最多给建模分析用，但普通的预测模型直接使用文件，pandas 就能很好处理，根本不需要读你的数据库。

[luziafy]

单表就行 十年后再说

[cominghome]

字段不多、对耗时不敏感的话放心用，mysql 配置跟得上单表几千万行没事的。

从架构层面来说，你的方案没有问题。如果用户量级不会急速膨胀也可以考虑按其他因素分表也是可以的，比如按 userid 尾数 0~9 可以分出十个表来，像你这种情况稳定跑个几十年都没事。

[Yukineko]

按年分区，800w 不是随随便便

[zhangqian99]

我司的一张表 8 个字段，运行两年 3 亿 3 千万行数据，占用存储 22G 。你的一年才 800 万行，担心啥，你太小看 mysql 了

[LieEar]

800 万这个级别 mysql 绰绰有余

[kiwi95]

加大内存甚至不用分表，节省下来的开发费维护用够加内存的了

[SoulSleep]

800 万/年。。。一行就几个字段....统计、分组排序.......单表够了
而且你这数据只写不改，如果统计、分组有压力可以做报表预处理，本来数据都是一小时一条....不需要实时查的，跑个 10 年都没压力

[wbrobot]

我 MySQL 5.7 老版本，单表 4 亿也没说啥啊，你 800 万零头都不到啊。。。好奇怪的帖子

[franchise]

这量级单表，按周期做统计即可

[YetToCome]

这个数据量，建议不要单表，业务的方向很快就会膨胀到单表支撑不了的。
统计单独写代码提前计算

[wbrobot]

@zhangqian99 确实，我看了一下我的，又一年过去，已经增加到 5 亿 2 千万了，数据 21G,索引 29G ，一台每月 5 刀的 VPS 跑的飞快。。。

[nanrenlei]

一年 800w 的话 mysql 单表没问题，我们有的单表存储了 2000w ，但是统计全量数据之类的就比较慢了大概需要十来秒中，如果不需要事务的话也可以用 mongodb 存储，mongodb 大概存 10 亿不是问题，也可以使用 influx 这种时序数据库，但要增加学习成本

[shyrock]

一年八百万，又不是一小时八百万。。。感觉这数据增加十分缓慢啊。。。

建议先用着，等你真正感受到性能瓶颈再说优化的事，记住”提前优化是万恶之源“。

[pkoukk]

能支撑，索引建好就行

[Jinnrry]

我这里评论表，单表 20 亿

[cenbiq]

确保你的操作都命中索引，然后把你最经常查询的字段（比如说最经常按数据的采集时间来查询）做成聚集索引，完事。

[whp1473]

如果只是简单统计，团队能控住，可以考虑上时序数据库，如果复杂统计不要求事务可以 Starrocks 、Clickhouse 。
如果还是想用 MySQL ，用 MySQL 也可以，单表 mysql 8000 万只简单查询没什么问题的，可以每 10 年一张表，简单检索直接走该表，分表字段为年区间比如 2014-2024 ，现成的框架就有，不用配置表；如果希望复杂维度统计，比如每一栋的室温、峰值、中位数、百分位，并且可以下钻，可以通过每天定时任务定时统计保存，如果数据量非常大了，比如几十亿，可以通过 Datax 抽取到 Hive 中处理跑批处理，如果希望数据实时，可以通过 Kafka+Flink 实时计算，再通过 Hive 或 Spark 批处理校准，批流配合。