再谈数据库优化:大量复杂查询下的系统反应慢问题!

[数据库技术] 季雨林 2021/10/14 22:17:34

在以前的工作经历中,虽然经历过高并发写入场景的GPS业务,却没有经历过ERP系统的复杂查询场景。最近接触的一个项目让我简隋英hi到了区别。

ERP项目,最典型的显然是读取场景要多得多,各种视图+函数+组合统计,让数据库读数据负载居高不下。甚至说找到这个系统慢的原因都反复不彻底。最近在这个项目我的经历如下,用的是SQL Server数据库:

1,数据库有死锁!

死锁是个严重的问题,赶紧看看什么场景。扫过表结构一看,居然没有用索引。各种查询集中在记账核心业务表上接二连三不间断,可不就是在争用锁嘛!

2,数据库表居然没有索引!

这一发现让我一上来就认为自己找到了问题所在,于是乎连续几天,翻查代码和视图,各种找where后面的条件,进行索引添加动作。然而问题来了,提升了不少,死锁问题也没在看到。自己各种页面看了一圈感受到了提升,本以为已经好了很多,喊了几个人一起测一下,还是慢。

3,集中查询导致的硬盘队列飙升!

由于看到了几个人同时做相同的操作时候会慢,一个人查询列表,另外2个人的写入都明显延迟。根据这一点现象,我盯着服务器硬盘看了下,队列动不动就飘到几十上百,这还了得!

应对办法,加缓存,屏蔽集中查询,几个人都打开同样的列表,那就干脆最近这几秒都是用同一个查询结果返回即可。

4,统计页面还是慢!

已经用了缓存,但是缓存只解决并发读问题,并没有真正解决计算量大问题,所以这时候我的注意力集中在了视图上,经过查阅了解到一个知识点:视图,表变量,表分区等使用,会导致系统数据库tempdb读写量巨大,回到磁盘监控看了下果然是,读写最多的就是tempdb,而且磁盘队列高的时候几乎一定是tempdb排在第一个。

这里难度就大了,可能真得动代码结构了,前面的查询几乎没写过几行代码。这一步看来逃不过了。老老实实逐个看代码吧,果然各种统计都是直接用的视图,更要命的是都是时间入参动态统计所有,动辄就要使用几十万源数据进行表关联。这一步就没法偷懒了,我去改代码了,没时间写博客了。。。。


原文地址: https://www.opengps.cn/Blog/View.aspx?id=931 文章的更新编辑依此链接为准。欢迎关注源站原创文章!

评论

暂无评论!

发表评论:

用于接收作者回复信息
点击更换验证码 - openGPS提示