SQL Server数据库对上亿表的操作
导读: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一个预警邮件,我们收到邮件后可以立即做相应处理。
针对四:
日志文件目前已经涨得较大,我们执行一下截断日志的动作,将日志文件的空间使用保持在一个较低水平。
上文中首先是为大家分析出了这个问题的所在,紧接着,又为大家总结出了解决方案,相信已经是非常清楚明白啦,希望能够对大家有所帮助。
【编辑推荐】
相关文章
- 从本体论开始说起——运营商关系图谱的构建及应用
- 如何成为一名数据科学家?
- 从未见过的堂兄杀了人,你的DNA是关键证据
- 20个安全可靠的免费数据源,各领域数据任你挑
- 20个安全可靠的免费数据源,各领域数据任你挑
- 阿里云李飞飞:All in Cloud时代,云原生数据库优势明显
- 基于Hadoop生态系统的一高性能数据存储格式CarbonData(性能篇)
- 大数据告诉你:10年漫威,到底有多少角色
- TigerGraph:实时图数据库助力金融风控升级
- Splunk利用Splunk Connected Experiences和Splunk Business Flow 扩大数据访问
- 大数据开发常见的9种数据分析手段
- 以免在景区看人,我爬了5W条全国景点门票数据...
- 【实战解析】基于HBase的大数据存储在京东的应用场景
- 数据科学家告诉你哪些计算机科学书籍是你应该看的
- Kafka作为大数据的核心技术,你了解多少?
- Spring Boot 整合 Redis 实现缓存操作
- 大数据学习必须掌握的五大核心技术有哪些?
- 基于Antlr在Apache Flink中实现监控规则DSL化的探索实践
- 甲骨文再次被Gartner评为分析型数据管理解决方案魔力象限领导者
- 爬取吴亦凡微博102118条转发数据,扒一扒流量的真假