前事不忘,后事之师,不忘国耻!

 注册  找回密码
 注册

QQ登录

只需一步,快速开始

搜索
查看: 3380|回复: 1

[开发应用] SQL Server数据库对上亿表的操作

[复制链接]

[开发应用] SQL Server数据库对上亿表的操作

[复制链接]
ehxz

主题

0

回帖

7251

积分

管理员

积分
7251
2008-8-11 13:45:59 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?注册

×
对上亿的表进行排序或者上亿的表之间进行join,会导致系统失去响应。


◆1.我确实做了一个很大的查询,涉及的数据表有两亿条记录,而且有一个group by操作,造成CPU、内存和磁盘开销均很大。后来和微软的人重新实验了一下,我的查询确实会造成系统反应变慢。后来我们也实验了一下,在这个2亿的表上统计一下行数,即select count(*) from table1,用了1分钟,内存涨了5G左右,磁盘子系统负荷很大,CPU也突然提高。这说明这种上亿的表的操作会非常严重的降低效率。



◆2.整个服务器的磁盘分配是这样的,网站访问的数据库库位于磁盘阵列中,而我们的统计临时库位于D盘中,C和D好像是一个磁盘组,也就相当于是在C盘。我们的数据库的大量磁盘I/O会导致系统的反应变慢。因此当我的查询很大的时候,就会使服务器整个系统变慢。



◆3.数据库的数据文件的自增长方式为每次1024k,数据文件的空间已经接近用光,而要发生增长,而增长空间要求应该比较大,所以就会不停的申请增长,造成磁盘开销较大。





◆4.操作中涉及到delete操作,会形成大量的日志,而上周扩容后,发现日志文件比以前缩小了,估计是重建了,昨天的操作会导致日志文件也要不断增长,也会造成磁盘的负荷加大。



解决办法:



针对一:

避免大表操作,所有的操作均可以按省或者时间分开,这样无论从时间或者地域维度,基本上可以将大表拆成30张以上的小表操作,甚至更多。然后再对结果进行合并,应该可以避免上述问题。



针对二:

无解决方案,只是建议将我们的数据库也单独分到一组磁盘上去,不要跟系统竞争。



针对三:

及时删除无用的临时数据,保障数据库空间,同时也可以做上空间监控,一旦数据文件空间发生增长时,给DBA一个预警邮件,我们收到邮件后可以立即做相应处理。



针对四:

日志文件目前已经涨得较大,我们执行一下截断日志的动作,将日志文件的空间使用保持在一个较低水平
免责申明1、欢迎访问本站,本文内容及相关资源来源于网络,版权归版权方所有!本站原创内容版权归本站所有,请勿转载!
2、本文内容仅代表作者观点,不代表本站立场,作者自负,本站资源仅供学习研究,请勿非法使用,否则后果自负!请下载后24小时内删除!
3、本文内容,包括但不限于源码、文字、图片等,仅供参考。本站不对其安全性,正确性等作出保证。但本站会尽量审核会员发表的内容。
4、如本帖侵犯到任何版权问题,请立即告知本站 ,本站将及时删除并致以最深的歉意!客服邮箱:admin@dbabbs.com
SiArg

主题

0

回帖

3

积分

初级会员

积分
3
2008-9-4 17:39:08 | 显示全部楼层
把系统缓存,库文件和日志文件放在不同的硬盘上。应该会好一点点
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

QQ|Archiver|小黑屋|DBA论坛中国 ( 鲁ICP备20017503号-2 )

GMT+8, 2024-11-1 07:55 , Processed in 0.035571 second(s), 12 queries , MemCached On.

Powered by Discuz! X3.5

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表