导读：SQL Server数据库的功能性很好，尽管如此，在面对上亿表的操作时，SQL Server数据库还是不行，速度很明显就慢下来啦，那么如何让SQL Server数据库在处理上亿表时，仍能够实现很高的工作效率呢？
大数量的操作带来的影响：
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一个预警邮件，我们收到邮件后可以立即做相应处理。
针对四：
日志文件目前已经涨得较大，我们执行一下截断日志的动作，将日志文件的空间使用保持在一个较低水平。
上文中首先是为大家分析出了这个问题的所在，紧接着，又为大家总结出了解决方案，相信已经是非常清楚明白啦，希望能够对大家有所帮助。
【编辑推荐】
