• 一个 Sql语句优化的问题- STATISTICS 统计信息


      前段时间,同事遇到一个 Sql语句的问题,一个列表分页功能响应在30 s以上,看数据库里面的数据条数,数据量也不大,相关字段的一些索引也都有,可就是慢。于是找出具体的sql 语句出来分析,分页功能主要有个sql 语句,select 查询和 count 两条语句。 select 查询字段的时候,速度挺快,执行时间在1 s以内 ,但是执行count(1)  的时候,速度巨慢,执行时间增加到10 s以上。奇怪的是count 语句为什么会比select 语句还慢呢。总之可以确定的就是count语句导致的。定位到具体的语句之后,查看具体的执行计划。发现select 语句的查询计划和count(1)的查询计划,有一些不同。

    Select 语句 的执行计划

     

    count(*)的查询计划

     

    以为是索引的问题。于是往各个表里面都加上的相关的索引,情况依旧,于是判断可能不是索引的问题。

    然后猜测是IO的问题。

    于是在两条sql 前后 加上SET STATISTICS IO ON; 查看IO情况。

    Select 语句的IO 输出

     

    Count(1) 语句的IO 输出

     

    对比后发现,ChannelBussinessInfo 这个表的逻辑读取,从2028次猛增到了631722 次,

    估计就是ChannelBussinessInfo 这个表的问题,于是尝试着给这个表加了一些相关的索引,但是依然没有效果。

    没有办法了,于是猜测是不是统计信息有问题,因为统计信息会影响 执行计划和io读取。

    顺着这个思路,尝试着把ChannelBussinessInfo这个表统计信息更新了,

    UPDATE STATISTICS ChannelBussinessInfo;

    果然,sql 执行时间降低到1秒。IO 读取降到2028次。

    关于UPDATE STATISTICS 的相关说明:

      http://technet.microsoft.com/zh-cn/ms187348

  • 相关阅读:
    吃一堑长一智
    人做事 天看着
    【转贴】英语中12个月名称的由来
    4199,流氓中的流氓
    【转贴】看D片容易误解的10个词组
    【转载】中国小吃(英文表达)
    拼死拼活为了啥!
    GCII 1.4对1.31改进
    上古III的汉化和美化修正
    linux下tar的用法
  • 原文地址:https://www.cnblogs.com/zhangweizhong/p/3849469.html
Copyright © 2020-2023  润新知