› MySQL 5.5 Community Server
› MySQL 5.6 Community Server
› Percona Configuration Wizard
› XtraBackup 搭建主从复制
Great Sites on MySQL
› Percona
› MySQL Performance Blog
› Severalnines
推荐管理工具
› Sequel Pro
› phpMyAdmin
推荐书目
› MySQL Cookbook
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
有个室温采集系统，一共 1686 个住户，每小时取一次数，供热季从 10 月份取到明年 4 月份，大约
1686*24*30*7=8,497,440 条数据，后期涉及到统计，分组排序等。
目前想到的办法是一年新建一张表，存储历史，然后做个配置表去管理查询哪张表。各位有在实际中遇到过相似问题的吗？有更好的办法吗？
1686*24*30*7=8,497,440 条数据，后期涉及到统计，分组排序等。
目前想到的办法是一年新建一张表，存储历史，然后做个配置表去管理查询哪张表。各位有在实际中遇到过相似问题的吗？有更好的办法吗？
第 1 条附言 · 18 天前
首先感谢各位 v 友给出的建议，我总结了下
1 、mysql 单表几千万上亿都没啥问题，不用考虑那么多（也可以索引、分区、分表）
2 、使用数据库 pgsql
3 、使用时序数据库
服务器没真实跑过这么大的数据，我云服务器跑几百万条数据就很慢了（当然配置也比较低），既然大家都说 mysql 没问题的话，那我就先实际运行试试，有问题再说，再次感谢各位 V 友们！
1 、mysql 单表几千万上亿都没啥问题，不用考虑那么多（也可以索引、分区、分表）
2 、使用数据库 pgsql
3 、使用时序数据库
服务器没真实跑过这么大的数据，我云服务器跑几百万条数据就很慢了（当然配置也比较低），既然大家都说 mysql 没问题的话，那我就先实际运行试试，有问题再说，再次感谢各位 V 友们！
119 条回复 • 2024-12-06 09:44:59 +08:00
 |
1
kuxuan 20 天前
收藏
|
 |
2
wowo243 20 天前
这不就是按年分表，分库分表有框架，比如 shardingsphere
|
 |
3
CodeCodeStudy 20 天前  2
可以用时序数据库，比如 influxdb 之类的
|
 |
4
akira 20 天前
统计，分组排序 提前算好就行 啦
|
 |
5
hefish 20 天前 1
10 年才 8000 多万，100 年才 8 亿多。。。。一年建一张表也行，就是分析统计跨年度的时候要额外处理一下。。。
实在不行还可以分区嘛，根据时间分区，这样落在一个数据库文件里的数据量就更有限了。。。 |
 |
6
linauror 20 天前
都按年存了，其实不必搞什么配置表，直接不让跨年查明细就好了，主要是控制一下明细的时间范围。
统计的话可以单独搞个统计表，每天跑一次之类的，这点数据问题不大 |
 |
7
Martens 20 天前
这种数据可以用时序数据库
|
 |
8
dynastysea 20 天前 4
mysql 哪里有这么脆弱啊，单标现在最大都可以支持到几十 TB 了，别被网上的一些垃圾文章误导。直接去买云厂商的产品，几亿条都没问题。
|
 |
9
yuzo555 20 天前
建议时序数据库
|
 |
10
HunterPan 20 天前
分区吧 10 年数据够用了
|
 |
11
whoosy 20 天前
800w 数据小意思
|
 |
12
wxw752 20 天前
一年才八百万，直接上云服务的数据库，哪怕存几年，这点量 查起来都没什么感觉
|
 |
13
cedoo22 20 天前 3
800W ，室温数据，没啥复杂的数据结构，主要是查询（统计），统计提前跑任务，
我觉得时间索引一下，10 年、8 年 归档一下就行了，分啥库分啥表。。。 |
 |
14
justfindu 20 天前
我们有个统计表, 一个月是 4000 万数据, 偷懒单表, 不过可以归档. 3 个月一归档.
|
 |
15
dddd1919 20 天前
不可变时序数据，上 hive
|
 |
16
weilai99 20 天前
单表八百万一点问题都没有，我们单表将近两千万都轻轻松松
|
 |
17
shen13176101 20 天前
想复杂了，业务就那么简单，不相信 mysql 换 pg
|
 |
18
systemGuest 20 天前
你太看不起 mysql 了，我们单表最大 8 亿的设备登录记录，照样正常查。
但是你要做各种复杂统计，就需要把数据同步过去，用 ES 类似专业的玩意。 |
 |
19
cheng6563 20 天前
一年 800 万...等你一天 800 万在考虑这些吧...
|
 |
20
jiakme 20 天前
如果允许的话, 可以考虑将 mysql 更换为 pgsql. 简单数据, 单表 1 亿没问题
|
 |
21
zdw406 20 天前
800w 数据量不算大
统计可以提前跑批，按需求设计专门存统计数据的表 一个主表可以存当前时间往前间隔固定时间（比如当前时间之前 1 年）的数据，历史表分表，这个数据量用不着分库 |
 |
22
molika 20 天前
docker 里面跑的 mysql 云虚拟机 一年跑了 4000 多 w 条数据 还会连表查询..目前没有任何压力
|
 |
23
jimrok 20 天前
800 万单表存储是没有问题，估计你也不开放查询给用户使用，这种数据最多给建模分析用，但普通的预测模型直接使用文件，pandas 就能很好处理，根本不需要读你的数据库。
|
 |
24
luziafy 20 天前
单表就行 十年后再说
|
 |
25
cominghome 20 天前
字段不多、对耗时不敏感的话放心用，mysql 配置跟得上单表几千万行没事的。
从架构层面来说，你的方案没有问题。如果用户量级不会急速膨胀也可以考虑按其他因素分表也是可以的，比如按 userid 尾数 0~9 可以分出十个表来，像你这种情况稳定跑个几十年都没事。 |
 |
26
Yukineko 20 天前
按年分区，800w 不是随随便便
|
 |
27
zhangqian99 20 天前
我司的一张表 8 个字段，运行两年 3 亿 3 千万行数据，占用存储 22G 。你的一年才 800 万行，担心啥，你太小看 mysql 了
|
 |
28
LieEar 20 天前
800 万这个级别 mysql 绰绰有余
|
 |
29
kiwi95 20 天前
加大内存甚至不用分表，节省下来的开发费维护用够加内存的了
|
 |
30
SoulSleep 20 天前
800 万/年。。。一行就几个字段....统计、分组排序.......单表够了
而且你这数据只写不改，如果统计、分组有压力可以做报表预处理，本来数据都是一小时一条....不需要实时查的，跑个 10 年都没压力 |
 |
31
wbrobot 20 天前 1
我 MySQL 5.7 老版本，单表 4 亿也没说啥啊，你 800 万零头都不到啊。。。好奇怪的帖子
|
 |
32
franchise 20 天前
这量级单表，按周期做统计即可
|
 |
33
YetToCome 20 天前
这个数据量，建议不要单表，业务的方向很快就会膨胀到单表支撑不了的。
统计单独写代码提前计算 |
|
34
wbrobot 20 天前
@zhangqian99 确实，我看了一下我的，又一年过去，已经增加到 5 亿 2 千万了，数据 21G,索引 29G ，一台每月 5 刀的 VPS 跑的飞快。。。
|
 |
35
nanrenlei 20 天前
一年 800w 的话 mysql 单表没问题，我们有的单表存储了 2000w ，但是统计全量数据之类的就比较慢了大概需要十来秒中，如果不需要事务的话也可以用 mongodb 存储，mongodb 大概存 10 亿不是问题，也可以使用 influx 这种时序数据库，但要增加学习成本
|
 |
36
shyrock 20 天前
一年八百万，又不是一小时八百万。。。感觉这数据增加十分缓慢啊。。。
建议先用着，等你真正感受到性能瓶颈再说优化的事，记住”提前优化是万恶之源“。 |
 |
37
pkoukk 20 天前
能支撑，索引建好就行
|
 |
38
Jinnrry 20 天前 via iPhone
我这里评论表，单表 20 亿
|
 |
39
cenbiq 20 天前
确保你的操作都命中索引，然后把你最经常查询的字段（比如说最经常按数据的采集时间来查询）做成聚集索引，完事。
|
 |
40
whp1473 20 天前
如果只是简单统计，团队能控住，可以考虑上时序数据库，如果复杂统计不要求事务可以 Starrocks 、Clickhouse 。
如果还是想用 MySQL ，用 MySQL 也可以，单表 mysql 8000 万只简单查询没什么问题的，可以每 10 年一张表，简单检索直接走该表，分表字段为年区间比如 2014-2024 ，现成的框架就有，不用配置表；如果希望复杂维度统计，比如每一栋的室温、峰值、中位数、百分位，并且可以下钻，可以通过每天定时任务定时统计保存，如果数据量非常大了，比如几十亿，可以通过 Datax 抽取到 Hive 中处理跑批处理，如果希望数据实时，可以通过 Kafka+Flink 实时计算，再通过 Hive 或 Spark 批处理校准，批流配合。 |
 |
41
luobingit 20 天前
才 800w 单表足够了 之前开发的系统一年十几亿 单表也没啥问题 复杂查询走 ES 注意磁盘 遇到瓶颈再优化 这点数据 就整分库分表了 不至于吧
|
 |
42
meeop 20 天前
800w 数据，你拿你的手机当服务器都没有问题
现在 2024 年了，任何数据承担 800w 数据都没有任何问题，甚至 800w 数据你全读取到内存里都没问题 哪找你提供的信息，一行数据 id+读数+时间+状态+ext ，算 300 字节，800w 行约 2.2G ，不到一部电影大小 |
 |
43
yoyolichen 20 天前
不管是单表还是分表，统计都建议提取个中间表，每天定时任务跑一下
|
 |
44
qq135449773 20 天前
存进去是没什么问题，可是之后怎么去用里面的数据，索引怎么设计优化，才是关键的问题。
把这种传统数据库当时序库用，一时间有点想不出来索引怎么去做.... |
 |
45
noyidoit 20 天前
太小看 mysql 了，遇到问题再说吧
|
 |
47
dilu 20 天前
太小看 mysql 了，第一家公司，7 年前。有一个流水表，十几亿的记录，二十多个字段，加了合适的索引。数据十几个 g ，索引也有十几个 g ，用的还是 4h8g 的配置，不过用的是腾讯云的 mysql 。
app 是 2w 日活左右，正常查询，接口平均都在 1s 以内，一点压力都没有。 |
 |
48
rickiey 20 天前
按年分表也没问题，这些数据是不是收集完后基本不会变，可以存在其他更合适的数据库，比如 clickHouse
|
 |
49
la2la 20 天前
1. 你这个业务场景不涉及到复杂事物场景，1 年 800w 数据 MySQL 完全抗的住
2. 挂个从库统计分析的需求只用从库 或者 通过 ETL 工具实时导入到 OLAP 数据库支持分析操作 3. 一年 800 万数据可以按 5 年分表都行，OLAP 数据库使用月分区 |
 |
50
reeco 20 天前
Mysql 单表 我极限存过 2 亿数据
|
 |
51
ShinichiYao 20 天前
当年也挺担心 MySQL 的单表大数据性能，10 年前的硬件 6 核 8G 内存，单表每月新增一个分区，最近看了一下，已经 19 亿数据了
|
 |
52
Meld 20 天前
每个三到五个供热季分一个表，随便搞
|
 |
53
assiadamo 20 天前
一张表存无压力，过几年再看
|
 |
54
luorixy 20 天前
是不是大家都对 MySQL 的性能都很担忧啊 一年才 800 万的量都担心了 MySQL 在大家眼里的性能这么差吗😂
|
 |
55
xuelu520 20 天前
这才多少数据，单表 10 年都不是问题
|
 |
56
gbw1992 20 天前
单表查询没啥问题，做分区就行了
麻烦的是可能有设计复杂的统计 |
 |
57
decken 20 天前
上亿都没问题 MySQL 性能不差的
|
 |
58
ymy3232 20 天前
一张表可以用到项目倒闭，你的项目还不一定能活 10 年，能活十年的项目有的是办法优化
|
 |
59
superchijinpeng 20 天前
一点问题没有
|
 |
61
THESDZ 20 天前
与其担心这个，不如担心备份问题。
|
 |
62
julyclyde 20 天前
1 不需要解决
2 用 tsdb 更合适 3 时间长了就可以删了。你又不是气象局，留那么远期的数据干啥？ |
 |
63
johnlin 20 天前
我们 2000w 条数据都存一张表的，800w 可以的。不跨年查询的话，你一下子建 20 张表 [20 年] ，然后建立一个字典，每个年度一张表，后期都不用你维护的
|
 |
64
cccvno1 20 天前
单表直接存，室温数据分布应该挺密集的，只要索引加好，普通机械硬盘都没有问题。
|
 |
65
0x663 20 天前
 一年才 800 万至于分表？ |
|
66
0x663 20 天前
而且一看你这个系统名称我就明白了是绩效项目，《室温采集系统》
估计热不过两年领导升上去了就不会管了。 |
 |
67
JZen 20 天前
800w 应该可以随便跑，以前我的双核垃圾服务器存 2000w 行的表都不慌，要做复杂统计可以把数据 dump 出来，在其他性能更高的机器上做。
|
 |
68
luciankaltz 20 天前
看起来还是一个时序指标的场景
不知道历史的统计要不要频繁查询，不过愿意等的话查询语句写的好应该问题也不大 数据直接存对象存储上，800w/年 的数据放个几年问题都不大（甚至再来几倍都 懒得写重复的回答了，ref https://www.v2ex.com/t/1093560#r_15605476 |
 |
69
encro 20 天前
一年 800 万，啥都不用干分表分区分库都不用管，3 年后再看就是了。。。
统计专门做统计表。 建议采用 postgresql ，哈哈。 |
 |
70
wangyzj 20 天前
你这个类似 iot 场景了，不适合 mysql
|
 |
71
gerryzhu0033 20 天前
不想麻烦的，直接用 mysql + 分区表，统计分组的话后面加个 clickhouse ，妥妥的
|
 |
72
go522000 20 天前
看到大家的数据都到亿了，真强大。
我之前一台轻量服务器，2C4G ，MYSQL 是那种官网直接下载安装的，没有修改配置，单表超过 200M 就会卡，是需要什么优化吗？ |
 |
73
chengxiao 20 天前
是不是看多了那个什么单表 2000w ,思维固化了
要知道技术和硬件这些年都在进步 ,单表 2000w 都快 10 年前的事了 |
 |
74
fengpan567 20 天前
Mysql:看不起谁呢？
|
 |
75
GreenHand 20 天前
我记得十年前我们单表就存了 10 亿级别的数据了
|
 |
76
FightPig 20 天前
800w 没问题吧，我没怎么用 mysql,我们的 pg 现在单表上亿，没发现什么毛病
|
 |
77
soul11201 20 天前 via Android
这点数据很多吗？
|
 |
78
RangerWolf 20 天前
我们单点 mysql 存储了 1T+的数据（没有分布式、也没有主从，只要每天备份）
只要不是频繁用来做数据分析，加上索引设计合理，800W 一年应该毫无压力 |
 |
79
ksc010 20 天前
一年 800w 不算事
|
 |
80
realpg 20 天前
我的单表一天就八百万数据
不过会把 30 天后的转到归档表 |
|
81
realpg 20 天前
每时每刻都在嗷嗷新增数据 不过晚上新增速度比较少
 一直在新增 count 就比较慢 |
 |
82
mingtdlb 20 天前
来到我司后，我想明白了我司 几乎所有的研发 做事风格都是顾前不顾后，工作量自己创造。
渐渐的我也想明白了，明年都不一定在这公司了，前人栽树 后人凉，埋点坑问题不大，何况你这个不算坑 |
 |
83
w3cll 20 天前
才 800w 而已，你是有多看不起 MySQL ？我们这边单表三四千万都轻轻松松
|
 |
84
mooyo 20 天前
八百万啊，你等八千万了再回来问吧。。
|
 |
85
Xhack 20 天前
@zhangqian99 主键用的啥
|
 |
86
RicardoY 20 天前
@CodeCodeStudy 没必要没必要，这才多少点数据量
|
 |
87
kkbear 20 天前
一年 800w ？？ mysql 被黑成这样了吗？
|
 |
88
esee 20 天前 via Android
你是不是没有正经做过项目都是写个 demo 就没了。mysql 没这么脆弱，我一个表两三年时间了三四亿行数据了，现在也没性能瓶颈。
|
 |
89
open9527 19 天前
这个项目能坚持十年吗
|
 |
90
yufeng0681 19 天前
@zdw406 #21 题主一个回复都没有，感觉浪费了大家一腔热情。
没有明确好需求，就开始设计表。 扩展性也是基于未来可能的新需求来考虑，而不是过度设计。 固定的业务统计报表需求，肯定会把数据采集计算形成统计使用的表结构 基于某 1 个用户的详情查询，用户 ID 做索引，查询速度没问题。 |
 |
91
iv8d 19 天前
一年上亿了再喊我，##
|
 |
92
visper 19 天前
干十年八千万了，你也离职了，留给后人烦恼，说不定项目已经被停归档了。
|
 |
93
bthulu 19 天前
目前八亿单表没问题, 等你数据到八亿了, 硬件也早就日新月异了, 更不用担心了
|
 |
94
onesuren 19 天前
这个场景 时序数据库比较合适。
|
 |
95
NoKey 19 天前
我们用的 pgsql ，一年 2 亿多数据，现在 2 年了，还是单表，除了一些改字段，大批量更新很慢之外，正常写入查询几乎感觉不到啥性能问题。所以，先找目标数据库进行压测，测试完了看结果再说，网上一些老八股文讲的什么几百万分库，都是早些年的环境下的结论了
|
 |
96
JingKeWu 19 天前
 一年的数据 单表 都是热数据 |
|
98
JingKeWu 19 天前
  |
 |
100
sazima 19 天前
之前做物联网相关的，一天 6000w 数据， 单表。
|
Select Language