none
有索引的查询将磁盘IO占满,不知怎么找原因 RRS feed

  • 问题

  • 1、相关配置信息(某云)

    Microsoft SQL Server 2014 - 12.0.4100.1 (X64) 

    Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz 4核 

    RAM 8G

    SSD (资源监视器显示满载时某mdf读150M)

    2、故障描述(无故障时各资源占用很低

    经常有磁盘满载卡死,资源监视器显示某mdf读150M,cpu不到50%。怀疑是以下SQL语句问题

    3、问题表部分结构(RefParma 字段内容为无序非定长,但基本唯一


    4、物理最高读报表

    5、实际分析

    2017年8月1日 9:38

全部回复

  • Did you check execution plan?
    2017年8月1日 12:19
  • 确定是这个查询导致的?

    如果是,打开 set statistics io on ,然后执行查询年看 IO 的开销

    2017年8月2日 2:19
  • (1 行受影响)
    表 'TB_Traffic_Log'。扫描计数 1,逻辑读取 4 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

    这么少。那我该从哪下手呢

    2017年8月2日 8:27
  • 那不会是这次查询引起的。你都说这么少了。

    想不想时已是想,不如不想都不想。

    2017年8月2日 10:26
    版主
  • 建议 profile 一下,把 IO 最高,或者 IO 不太高,但并发特别大的查询弄出来
    2017年8月3日 3:00
  • 

    这是最高平均IO的信息。此表所有索引基本无碎片

    如字段类型或其他有问题请指正


    2017年8月3日 3:53
  • 检查一下这个查询的 IO 开销,别晚,这个执行计划明确提示缺少合适的索引
    2017年8月4日 1:11
  • 另外,你用的是 ssms 里面的报表得到的这个查询吧?

    这个是自 sq 启动以后的总休情况,而你要排查的是特定的故障,这两者是有出入的,所以通常是建议你 profile 故障时间点的信息,这样的信息才能准确反应故障时间点的情况

    2017年8月4日 1:28
  • 等了几天问题暂未重现。sql server 2016中的列存储索引试了下,看分析和IO统计比以前要好不少,准备将以前的组合索引改成列存储。这个可行不

    (之前where后的字段不定,经常导致组合索引失效)

    2017年8月8日 10:01
  • Hi 孤单一吻,

    列索引确实可以减少内存和I/O的使用,但是是否将全部索引换成列索引还要看具体的情况。

    Best Regards,

    Teige


    MSDN Community Support<br/> Please remember to click &quot;Mark as Answer&quot; the responses that resolved your issue, and to click &quot;Unmark as Answer&quot; if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact <a href="mailto:MSDNFSF@microsoft.com">MSDNFSF@microsoft.com</a>.

    2017年8月18日 8:36
    版主
  • 再发现io占满的时候,看查询进程里有多少的等待 是pageio开头的;重点分析这这种等待的查询语句及表;

    select * from master..sysprocesses where lastwaittype like 'pageio%'

    2017年9月11日 6:05
  • 我建议你直接从整个实例入手吧:

    USE master
    GO
    SELECT TOP 20
        execution_count, 
        total_worker_time/1000 AS total_worker_time_ms,  
        total_logical_reads/execution_count as avg_logical_reads,
        total_physical_reads/execution_count as avg_physical_reads,
        total_elapsed_time/execution_count/1000 as  avg_elapsed_time_ms,
        max_elapsed_time/1000 as max_elapsed_time_ms
        [text]
    FROM 
        sys.dm_exec_query_stats qs
    CROSS APPLY 
        sys.dm_exec_sql_text(qs.sql_handle) AS st
    ORDER BY 
        4 DESC
    找出物理读最高的几个SQL,一个个查看执行计划会有收获的。

    2017年9月15日 6:08