一张表，一天230万条数据，这个业务有没有问题？

有多个终端设备，每次发回来的数据都要保存到某张信息表中
实验了一天，结果，写了230万条数据到该表中

这个是不是设计有问题？这样一年下来这张表数据得疯掉啊

情况说明：
SQL Server2005
有1000个终端设备，每分钟都会发送数据过来
我接收到数据，就保存到信息表中。这样一天下来数据太多了

探讨一下，有什么好的设计方式？
分多张表存放？

12 个解决方案

#1

考慮分區表，每個終端都分一個表出來，減輕壓力。
要查詢時可以針對某一個終端的數據進行查詢。

#2

有没有更简单的方式？

#3

一个终端一个表比较好

#4

一天几千万笔记录的案例也有，２３０万并不多

#5

一天230W，一年下来量就非常大了。这些数据存储完了以后你打算怎么用，这个会影响到你以后的优化？比如分表？分区？

#6

兄弟，我们两个是同命人，你还好，系统还没有上线，我的已经上线两年了，当时前面兄弟没有考虑到数据增长问题。我个人感觉你要从这几个方面入手：希望对你有点帮助
1. 数据库一定要用64位的；
2. 根据业务特点进行均衡负载（构建多台服务器，根据不同的业务访问不同服务器）；
3. 细分数据，对于非关系数据的使用非关系数据库（MangoDB).

#7

老大们
你们构建的太复杂啊
我这个做的东西只是展示一下用的，统计和查询一下的
一个东东，项目才1万块钱啊。。。

#8

简单的话，可以考虑分表实现：

按业务分：明细表 和 统计表
按水平分割：一个活跃表，一个历史表

那么在数据库中至少需要4个表。

每天的明细数据写入明细表（活跃），不需要查询的历史明细数据，搬至明细表（历史）。
每天的统计数据作一个统计写入统计表（活跃），过期的数据搬至统计表（历史）。

#9

我同意8楼的意见，还有按照设备分表也可以，统计的时候UNION呗

#10

引用 8 楼 DVD_01 的回复:

简单的话，可以考虑分表实现：

按业务分：明细表 和 统计表
按水平分割：一个活跃表，一个历史表

那么在数据库中至少需要4个表。

每天的明细数据写入明细表（活跃），不需要查询的历史明细数据，搬至明细表（历史）。
每天的统计数据作一个统计写入统计表（活跃），过期的数据搬至统计表（历史）。

同意，好办法

#11

SELECT 1000*60*24

--1440000

每天的数据量并不是很大。年5亿左右数据还可以。

查询历史数据，建议lz使用归档，分表处理。
平常的查询，做好索引，建好分区就够了，若有报表需求，ssis 处理个亿把数据不是问题。

#12

我现在的观点是，搬迁数据成本太高，以后维护非常麻烦
需要的话可以冗余，除了原始数据可以增加统计表，按统计需求增加

原始数据可以直接分表，比如一天一个表，一月一个库，写个存储过程负责写入，根据数据日期确定写入的表，动态写入；写个存储过程负责查询，根据常洵日期范围循环查询需要查询的表

这个方法现在是麻烦点，但是以后几乎没有维护量，处理历史数据只需要备份和删除过时的月库就可以