每天增加1000万条记录,如何尽量快速准确地实现多维的报表查询?

时间:2021-03-04 23:20:59
我现在想到的方法是拆分表,
比如3天一张表,
需要多天查询的时候把这些表再组合起来查询,
我这种思路正确与否?
请高手指教!

现在用的平台是sqlserver 2000  .
是不是需要用到数据仓库了呢 ?

9 个解决方案

#1


每天1000万,一年就是365000万,没有这么厉害的sql server,查询速度肯定慢。
拆开后再组合也会慢的。

#2


没必要拆分表,否则数据处理更需要时间主要还是考虑使用合理的索引以及其它数据优化,先找出性能的瓶颈所在,然后找出影响性能的"热点"进行分析和针对性解决.当然拆分也并不是不合理,只不过不应当是按时间拆分,除非你做处理的时候不需要再次合并,否则就是相关于"画蛇添足",可以考虑把一些冷门字段划分出来使用另一个关系表进行存储,(所谓冷门字段指的是那些使用相对没那么频繁的字段),将部分数据资料进行全理的压缩,比如某些可能使用中文字比较具备意义,一目了然,但是却需要占用大幅空间,而在数据处理当中是否需要这些有意义的中文字又没有多少影响,则可以考虑使用相对比较简短的规则性的字母+数字组成的伪编码进行替代,然后将这些中文字放到另一个关系表当中存储,然后使用替代这些文字的伪编码做为关键字进行关联.

#3


unsigned(僵哥(送人以鱼,不如授人渔;授人以渔,不如渔人之鱼)
同意

  建议对数据库进行两个存储,把对检索数据没有多少影响而存储空间大的字段进行伪码的替代,而把这些字段放到另一个表中存储。然后对这些字段的伪码进行检索就可以。

#4


up

#5


我觉得如果经常多天进行查询的话,就不要进行分表,
否则就分表,

#6


我们这里也有这样的情况,我们的处理方式是,单独创建一个数据库,然后做一个作业,作业每天晚上1点执行,根据一个日期字段,按天去创建或更新到另外的数据库,将负荷比较大的数据分离到其他的数据库,表名称就是日期,然后在原表中将处理过的数据删除,从而保证数据库的性能。

#7


学习一下,

#8


同意
gaojier1000(高捷)
的说法。
另外再顺便帮顶一下

#9


我没有一天1000W条的经验,但我做过一个每天一次性生成10W条数据的程序,久而久之,生成数据或查询时非常慢,客户和我们都无法忍受。
但最后我想出了一个用大量视图的例子,现在快多了,原来生成10W条数据,(当然从几个表中查询经过计算生成)需要10分钟左右,现在不到1分钟,查询也非常快。
你可以试试用视图。

#1


每天1000万,一年就是365000万,没有这么厉害的sql server,查询速度肯定慢。
拆开后再组合也会慢的。

#2


没必要拆分表,否则数据处理更需要时间主要还是考虑使用合理的索引以及其它数据优化,先找出性能的瓶颈所在,然后找出影响性能的"热点"进行分析和针对性解决.当然拆分也并不是不合理,只不过不应当是按时间拆分,除非你做处理的时候不需要再次合并,否则就是相关于"画蛇添足",可以考虑把一些冷门字段划分出来使用另一个关系表进行存储,(所谓冷门字段指的是那些使用相对没那么频繁的字段),将部分数据资料进行全理的压缩,比如某些可能使用中文字比较具备意义,一目了然,但是却需要占用大幅空间,而在数据处理当中是否需要这些有意义的中文字又没有多少影响,则可以考虑使用相对比较简短的规则性的字母+数字组成的伪编码进行替代,然后将这些中文字放到另一个关系表当中存储,然后使用替代这些文字的伪编码做为关键字进行关联.

#3


unsigned(僵哥(送人以鱼,不如授人渔;授人以渔,不如渔人之鱼)
同意

  建议对数据库进行两个存储,把对检索数据没有多少影响而存储空间大的字段进行伪码的替代,而把这些字段放到另一个表中存储。然后对这些字段的伪码进行检索就可以。

#4


up

#5


我觉得如果经常多天进行查询的话,就不要进行分表,
否则就分表,

#6


我们这里也有这样的情况,我们的处理方式是,单独创建一个数据库,然后做一个作业,作业每天晚上1点执行,根据一个日期字段,按天去创建或更新到另外的数据库,将负荷比较大的数据分离到其他的数据库,表名称就是日期,然后在原表中将处理过的数据删除,从而保证数据库的性能。

#7


学习一下,

#8


同意
gaojier1000(高捷)
的说法。
另外再顺便帮顶一下

#9


我没有一天1000W条的经验,但我做过一个每天一次性生成10W条数据的程序,久而久之,生成数据或查询时非常慢,客户和我们都无法忍受。
但最后我想出了一个用大量视图的例子,现在快多了,原来生成10W条数据,(当然从几个表中查询经过计算生成)需要10分钟左右,现在不到1分钟,查询也非常快。
你可以试试用视图。