提高SQL大数据量的查询性能
提高SQL大数据量的查询性能
我有一个表,千万级的数据,但是在查询的时候老是出现“网络超时”,这和服务器的硬件有关系,但是现在我想先从软件方面着手解决,也就是提高查询的性能。
现在想了想方案,和大家交流一下:
1、优化SQL语句,索引。(这不用说)
2、分表存储数据,以用户站点编号名称为一个表,打算这样做。但是不能解决实际问题,一个站点,20多天的数据就达600多万条。
3、做分区表(http://msdn.microsoft.com/zh-cn/library/ms345146%28v=sql.90%29.aspx),但是会带来其他方面的工作量,现在正在犹豫中。
大家讨论一下,俺也学习一下。
------解决方案--------------------分历史表和当前的表 当前的表最后转历史表。
------解决方案--------------------提升硬件性能,升级数据库版本。
------解决方案--------------------分区表
------解决方案--------------------
换成SQL2008?我现在用的是2005
------解决方案--------------------
这个问题我考虑过,当前表保存7天的数据,然后转入历史表,但是这些数据要处理和分析的,转入历史表也涉及这个问题,除非忽略历史表的数据。
谢谢。
------解决方案--------------------trace 然后优化
------解决方案--------------------优化sql,索引不用说了
为什么不用说了呢?
合理的索引可以在很大程度上提高性能
即便是分区,索引设计的不合理,也不会从本质上改善性能
------解决方案--------------------
肯定会做。
------解决方案--------------------先要分析业务需求,关心的是哪些重要数据,哪一范围的数据(时间范围,分类范围,数值范围等),
再考虑分区表,分库。
------解决方案--------------------做分表不合适
做到优化索引和建立分区表我感觉就差不多了
------解决方案--------------------2005以后,就多使用分区表吧。对固定的查询(基本上不会变更,比如历史表),可以使用索引视图。还有一种思路,就是分库,把只用于“查询”的部分分到一个库,原库用来做业务数据,这样可以检查阻塞、资源争用。单纯的千万级数据做得好的话也就几秒就能出来数据,肯定是有不合理的设计+不合理的编码+不合理的维护+不合理的配置所导致的超时
------解决方案--------------------转历史表,涉及业务逻辑改动
改为分区表,sql什么都无任何影响,几千万小意思
服务器内存多少?8G、16G应该都不贵了
------解决方案--------------------跪求哪位有分区表的实际应用
多大数据分区合理合适?测试过分区和不分区有明显的性能差别
我测试1500W的数据量,同样的数据,一个表分区,一个表不分区,
用聚集索引查询的话,性能上基本上没有什么区别
我估计性能受影响较大的还是非聚集索引了。没有具体测试过。
------解决方案--------------------把数据结构设计成为查询服务的, 用多维建模方法,不要用规范发模型去设计数据结构.
在有,可以考虑建立多维数据集合,也就是SSAS上的Cube,最好建立2个SSAS数据库,它们的分区粒度不同,具体规则要对数据考察,评估的基础上决定;
20天600万的数据量对当前领域来说,也不能算是大数据量.服务器的硬件还是必须的,如果连SQL Server本身运行都吃力,还怎么去提供数据服务啊.
------解决方案--------------------
是不算多,但是是一个站点的数据,要是全国站点数据,暂时无法估计。
------解决方案--------------------你分了区之后各个区有没有放在不同的磁盘呢?如果是同一个,那不会有性能提升