1

收藏

2

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

3

2

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

4

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

5

1

6

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

7

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

8

4

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

9

建议时序数据库

10

分区吧 10 年数据够用了

11

800w 数据小意思

12

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

13

3

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

14

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

15

不可变时序数据，上 hive

16

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

17

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

18

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

19

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

20

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

21

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

22

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

23

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

24

单表就行 十年后再说

25

26

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

27

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

28

800 万这个级别 mysql 绰绰有余

29

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

30

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

31

1

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

32

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

33

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

34

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

35

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

36

37

能支撑，索引建好就行

38

我这里评论表，单表 20 亿

39

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

40

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

41

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

42

43

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

44

45

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

46

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

47

48

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

49

1. 你这个业务场景不涉及到复杂事物场景，1 年 800w 数据 MySQL 完全抗的住
2. 挂个从库统计分析的需求只用从库 或者 通过 ETL 工具实时导入到 OLAP 数据库支持分析操作
3. 一年 800 万数据可以按 5 年分表都行，OLAP 数据库使用月分区

50

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

51

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

52

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

53

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

54

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

55

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

56

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

57

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

58

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

61

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

62

1 不需要解决
2 用 tsdb 更合适
3 时间长了就可以删了。你又不是气象局，留那么远期的数据干啥？

63

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

64

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

65

一年才 800 万至于分表？

66

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

67

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

69

70

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

71

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

72

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

73

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

75

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

76

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

77

这点数据很多吗？

78

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

79

一年 800w 不算事

80

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

81

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

一直在新增 count 就比较慢

82

83

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

84

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

87

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

88

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

89

这个项目能坚持十年吗

90

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

91

一年上亿了再喊我，##

92

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

93

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

94

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

95

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

96

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

100

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