经验总结：SQLServer数据库对上亿表的操作

对数亿个表进行排序或在数亿个表之间进行连接会导致系统失去响应。

◆1.我确实做了一个大的查询，涉及数据表中的2亿条记录，还有一个group by操作，造成了大量的CPU、内存和磁盘开销。后来我又用微软的人做了实验，我的查询确实让系统响应变慢了。后来我们也做了实验，统计这2亿张表上的行数，也就是从table1中选择count(*)。用了1分钟，内存增加5G左右，磁盘子系统负载较重，CPU突然增加。这说明上亿张表的操作会严重降低效率。

◆2.整个服务器的磁盘分配如下:网站访问的数据库位于磁盘阵列，而我们的临时统计数据库位于磁盘D，C和D好像是一个磁盘组，相当于在磁盘C，我们数据库大量的磁盘I/O会拖慢系统的响应。所以当我的查询量非常大的时候，会拖慢服务器的整个系统。

◆3.数据库中数据文件的自增长模式是每次1024k，数据文件的空快用完了，但是需要增长，对增长空的需求应该比较大，所以会不断申请增长，导致磁盘开销很大。

◆4.当操作中涉及删除操作时，会形成大量的日志。但是经过上周的扩展，发现日志文件比以前小了，估计是重建的。昨天的操作会导致日志文件不断增长，这也会增加磁盘负载。

解决方案:

首先:

避免大表操作。所有操作都可以按省或按时间分开，这样大表基本上可以拆分成30多个小表操作，甚至更多，不考虑时间或地理维度。然后合并结果，这样应该可以避免上述问题。

两个人:

没有解决的办法，但是建议我们的数据库单独分成一组磁盘，不要和系统竞争。

三个人:

及时删除无用的临时数据，保证数据库空，同时监控数据库空。一旦数据文件空增长，发送警告邮件给DBA，我们收到邮件后可以立即处理。

四个人:

目前，日志文件已经大大增加。让我们截断日志文件，以将日志文件的空的使用率保持在较低的水平。