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

收藏

这不就是按年分表，分库分表有框架，比如 shardingsphere

可以用时序数据库，比如 influxdb 之类的

统计，分组排序 提前算好就行 啦

10 年才 8000 多万，100 年才 8 亿多。。。。一年建一张表也行，就是分析统计跨年度的时候要额外处理一下。。。

实在不行还可以分区嘛，根据时间分区，这样落在一个数据库文件里的数据量就更有限了。。。

都按年存了，其实不必搞什么配置表，直接不让跨年查明细就好了，主要是控制一下明细的时间范围。
统计的话可以单独搞个统计表，每天跑一次之类的，这点数据问题不大

这种数据可以用时序数据库

mysql 哪里有这么脆弱啊，单标现在最大都可以支持到几十 TB 了，别被网上的一些垃圾文章误导。直接去买云厂商的产品，几亿条都没问题。

建议时序数据库

分区吧 10 年数据够用了

800w 数据小意思

一年才八百万，直接上云服务的数据库，哪怕存几年，这点量 查起来都没什么感觉

800W ，室温数据，没啥复杂的数据结构，主要是查询（统计），统计提前跑任务，
我觉得时间索引一下，10 年、8 年 归档一下就行了，分啥库分啥表。。。

我们有个统计表, 一个月是 4000 万数据, 偷懒单表, 不过可以归档. 3 个月一归档.

不可变时序数据，上 hive

单表八百万一点问题都没有，我们单表将近两千万都轻轻松松

想复杂了，业务就那么简单，不相信 mysql 换 pg

你太看不起 mysql 了，我们单表最大 8 亿的设备登录记录，照样正常查。
但是你要做各种复杂统计，就需要把数据同步过去，用 ES 类似专业的玩意。

一年 800 万...等你一天 800 万在考虑这些吧...

如果允许的话, 可以考虑将 mysql 更换为 pgsql. 简单数据, 单表 1 亿没问题

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

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

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

单表就行 十年后再说

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

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

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

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

800 万这个级别 mysql 绰绰有余

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

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

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

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

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

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

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

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

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

能支撑，索引建好就行

我这里评论表，单表 20 亿

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

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

才 800w 单表足够了 之前开发的系统一年十几亿 单表也没啥问题 复杂查询走 ES 注意磁盘 遇到瓶颈再优化 这点数据 就整分库分表了 不至于吧

800w 数据，你拿你的手机当服务器都没有问题

现在 2024 年了，任何数据承担 800w 数据都没有任何问题，甚至 800w 数据你全读取到内存里都没问题
哪找你提供的信息，一行数据 id+读数+时间+状态+ext ，算 300 字节，800w 行约 2.2G ，不到一部电影大小

不管是单表还是分表，统计都建议提取个中间表，每天定时任务跑一下

存进去是没什么问题，可是之后怎么去用里面的数据，索引怎么设计优化，才是关键的问题。

把这种传统数据库当时序库用，一时间有点想不出来索引怎么去做....

太小看 mysql 了，遇到问题再说吧

兄弟，哪家的 vps 硬盘这么大，挺划算。方便说下吗？我去看看，有没有更便宜的。

太小看 mysql 了，第一家公司，7 年前。有一个流水表，十几亿的记录，二十多个字段，加了合适的索引。数据十几个 g ，索引也有十几个 g ，用的还是 4h8g 的配置，不过用的是腾讯云的 mysql 。

app 是 2w 日活左右，正常查询，接口平均都在 1s 以内，一点压力都没有。

按年分表也没问题，这些数据是不是收集完后基本不会变，可以存在其他更合适的数据库，比如 clickHouse

1. 你这个业务场景不涉及到复杂事物场景，1 年 800w 数据 MySQL 完全抗的住

2. 挂个从库统计分析的需求只用从库 或者 通过 ETL 工具实时导入到 OLAP 数据库支持分析操作

3. 一年 800 万数据可以按 5 年分表都行，OLAP 数据库使用月分区

   Mysql 单表 我极限存过 2 亿数据

   当年也挺担心 MySQL 的单表大数据性能，10 年前的硬件 6 核 8G 内存，单表每月新增一个分区，最近看了一下，已经 19 亿数据了

   每个三到五个供热季分一个表，随便搞

   一张表存无压力，过几年再看

   是不是大家都对 MySQL 的性能都很担忧啊 一年才 800 万的量都担心了 MySQL 在大家眼里的性能这么差吗😂

   这才多少数据，单表 10 年都不是问题

   单表查询没啥问题，做分区就行了
   麻烦的是可能有设计复杂的统计

   上亿都没问题 MySQL 性能不差的

   一张表可以用到项目倒闭，你的项目还不一定能活 10 年，能活十年的项目有的是办法优化

   一点问题没有

   啥配置这么硬

   与其担心这个，不如担心备份问题。

   1 不需要解决

4. 用 tsdb 更合适

5. 时间长了就可以删了。你又不是气象局，留那么远期的数据干啥？

   我们 2000w 条数据都存一张表的，800w 可以的。不跨年查询的话，你一下子建 20 张表 [20 年] ，然后建立一个字典，每个年度一张表，后期都不用你维护的

   单表直接存，室温数据分布应该挺密集的，只要索引加好，普通机械硬盘都没有问题。

   一年才 800 万至于分表？

   而且一看你这个系统名称我就明白了是绩效项目，《室温采集系统》
   估计热不过两年领导升上去了就不会管了。

   800w 应该可以随便跑，以前我的双核垃圾服务器存 2000w 行的表都不慌，要做复杂统计可以把数据 dump 出来，在其他性能更高的机器上做。

   看起来还是一个时序指标的场景
   不知道历史的统计要不要频繁查询，不过愿意等的话查询语句写的好应该问题也不大
   数据直接存对象存储上，800w/年 的数据放个几年问题都不大（甚至再来几倍都

懒得写重复的回答了，ref www.hesudu.com/t/1093560＃r_15605476

一年 800 万，啥都不用干分表分区分库都不用管，3 年后再看就是了。。。

统计专门做统计表。

建议采用 postgresql ，哈哈。

你这个类似 iot 场景了，不适合 mysql

不想麻烦的，直接用 mysql + 分区表，统计分组的话后面加个 clickhouse ，妥妥的

看到大家的数据都到亿了，真强大。
我之前一台轻量服务器，2C4G ，MYSQL 是那种官网直接下载安装的，没有修改配置，单表超过 200M 就会卡，是需要什么优化吗？

是不是看多了那个什么单表 2000w ,思维固化了
要知道技术和硬件这些年都在进步 ,单表 2000w 都快 10 年前的事了

Mysql:看不起谁呢？

我记得十年前我们单表就存了 10 亿级别的数据了

800w 没问题吧，我没怎么用 mysql,我们的 pg 现在单表上亿，没发现什么毛病

这点数据很多吗？

我们单点 mysql 存储了 1T+的数据（没有分布式、也没有主从，只要每天备份）
只要不是频繁用来做数据分析，加上索引设计合理，800W 一年应该毫无压力

一年 800w 不算事

我的单表一天就八百万数据
不过会把 30 天后的转到归档表

每时每刻都在嗷嗷新增数据 不过晚上新增速度比较少

一直在新增 count 就比较慢

来到我司后，我想明白了我司 几乎所有的研发 做事风格都是顾前不顾后，工作量自己创造。

渐渐的我也想明白了，明年都不一定在这公司了，前人栽树 后人凉，埋点坑问题不大，何况你这个不算坑

才 800w 而已，你是有多看不起 MySQL ？我们这边单表三四千万都轻轻松松

八百万啊，你等八千万了再回来问吧。。

主键用的啥

没必要没必要，这才多少点数据量

一年 800w ？？ mysql 被黑成这样了吗？

你是不是没有正经做过项目都是写个 demo 就没了。mysql 没这么脆弱，我一个表两三年时间了三四亿行数据了，现在也没性能瓶颈。

这个项目能坚持十年吗

＃21 题主一个回复都没有，感觉浪费了大家一腔热情。
没有明确好需求，就开始设计表。
扩展性也是基于未来可能的新需求来考虑，而不是过度设计。
固定的业务统计报表需求，肯定会把数据采集计算形成统计使用的表结构
基于某 1 个用户的详情查询，用户 ID 做索引，查询速度没问题。

一年上亿了再喊我，＃＃

干十年八千万了，你也离职了，留给后人烦恼，说不定项目已经被停归档了。

目前八亿单表没问题, 等你数据到八亿了, 硬件也早就日新月异了, 更不用担心了

这个场景 时序数据库比较合适。

我们用的 pgsql ，一年 2 亿多数据，现在 2 年了，还是单表，除了一些改字段，大批量更新很慢之外，正常写入查询几乎感觉不到啥性能问题。所以，先找目标数据库进行压测，测试完了看结果再说，网上一些老八股文讲的什么几百万分库，都是早些年的环境下的结论了

一年的数据 单表 都是热数据

＃20 mysql 也没有问题

前人栽树 后人凉 笑死我了 兄弟

之前做物联网相关的，一天 6000w 数据， 单表。