我的一些SQLServer 优化

4 篇文章 0 订阅

一直在维护公司的系统,最近有客户投诉系统过慢,恩恩硬着头皮上去看吧

首先的话,我会先习惯性的看看数据库中的活动监视器,也就是下图最后的那个

打开后(如下图)

我会很习惯性的盯着下面的那一栏[最近耗费大量资源查询],我比较注重的是后面的逻辑读取次数和平均持续的时间

PS:可以选择一项的一个倒三角选择需要监视的的数据库名称,排除其他数据库的操作带来的干扰

在[逻辑读取次数]和[平均持续的时间]这两项中是最容易发现那个查询语句拖慢速度的,就好像我最近优化的一个数据库一样,逻辑读取次数50次不到,但是平均持续的时间居然到了5000+,也就是这一句话,直接把系统停在了登录页面(或许你会问才5000+毫秒,怎么也不会卡在那里吧!的确,只是这样就不会,要是在程序上面加了个JQ的定时执行函数的话,就不一样了)

事实上找到那个语句之后,差点晕倒!这句话居然是给提示的小窗体的数据源!连个滚动条都没有,居然要装下了3W+条数据!语句直接改成Top10,然后把括号里面的数字改成…..(恩恩,没错,这个是障眼法!),这样改完后,速度的确快了好多,虽然不能在具体数值上体现,但是至少公司的客户没有为登录不进去而投诉了(下图是改了之后的样子)

原来是在括号中显示具体数字,现在改成...;原来是下面是装了3W+的数据,现在是10条,那速度提高的真是没话说的

解决了这个问题后,紧接着是下面的工作记录打开很慢的问题,也就是点击处理(如下图)的时候,要等上一两分钟的才能打开窗口;

不断的排查后,问题锁定在一行代码上面也就是下面这行:

blProc.GetProcInfoByProcID(procID, out url, out width, out height, out KeyFieldName, out keyID);

后面是linQ写的,方法代码如下:    

	var info = (from proc in dc.TbWmProcs
                        join flow in dc.TbWmFlows
                        on proc.FlowID equals flow.FlowID
                        join action in dc.TbPcActions
                        on flow.ActionCode equals action.ActionCode
                        join form in dc.TbWmForms
                        on flow.FormID equals form.FormID
                        where proc.ProcID == procID
                        select new
                        {
                            form.Url,
                            form.Width,
                            form.Height,
                            action.KeyFieldName,
                            flow.AppID
                        }).First();


在上面的那句问题代码的前后加上两句代码,变成了下面的样子

 

 Stopwatch sw = new Stopwatch();
        sw.Start();
        blProc.GetProcInfoByProcID(procID, out url, out width, out height, out KeyFieldName, out keyID);
        sw.Stop();

        ScriptManager.RegisterClientScriptBlock(this, this.GetType(), "123", "alter('运行时间是" + sw.Elapsed + "')", false);

 

对了,那几张表的数据状况如下

运行->点击处理;

额~额~~报错了!

这个可能是模板页以及Updatepanel综合影响到了这个脚本的运行,

但是不管怎么样,我还是得到了这个语句执行完的时间00:00:00.1257938也就是125.7938毫秒(如下图)

会不会是linQ执行的效率慢?

换SQL语句看看!

换成了下面的代码

string sql = @"
SELECT Top 1 form.Url, form.Width, form.Height,
         action.KeyFieldName,
        flow.AppID FROM TbWmProc [proc] inner JOIN TbWmFlow flow
on [proc].FlowID=flow.FlowID
INNER join TbPcAction [action] 
on [action].ActionCode=flow.ActionCode
INNER join TbWmForm form
on form.ActionCode=[action].ActionCode where [proc].ProcID =" + procID;

得到了这个语句执行完的时间是00:00:00.0004631也就是0. 4631毫秒(如下图)

 

整整提高了271+倍!!

 

我猜测应该是是linQ的语句应该是翻译成SQL语句的时候花费的时间太多了,这个只是个人见解,具体的还要深入研究一下

 

改了这个linQ语句后,查了一下数据库中的表,上面都基本有索引,都重新组织了一下索引;

 

这次的优化后,我觉得吧,在开发效率和代码执行的效率上.还是得斟酌一下..

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值