You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

SQL Server旧日期查询正常,最新日期查询卡顿无结果的问题排查

查询性能差异原因分析

先贴出你的查询语句:

SELECT  
    tap1.[id],
    tap1.[Mark],
    tap1.[Date_Write]
FROM
    [crpt].[dbo].[BI] tap1
JOIN 
    (SELECT mark 
     FROM [crpt].[dbo].[BI]     
     GROUP BY mark  
     HAVING COUNT(mark) = 2) t ON t.mark = tap1.mark 
WHERE
    date_write > '2023-09-26' 
    AND date_write < '2023-09-28'
ORDER BY
    date_write, mark

导致新旧日期查询性能天差地别的可能原因如下:

  • 统计信息未更新:旧日期区间的数据统计信息已被SQL Server准确收集,查询优化器能基于这些信息生成高效执行计划(比如走合适的索引)。但新写入的2023-10-01至10-03的数据,统计信息还没自动更新,优化器误判数据分布,选择了低效的执行计划(比如全表扫描),直接导致卡顿。
  • 数据分布差异过大:新日期区间内,满足COUNT(mark)=2的mark数量远多于旧日期,子查询返回的结果集暴增,和主表join后的数据量远超预期,内存和IO资源被占满,无法快速返回结果。
  • 索引问题:
    • 新数据的date_write或mark索引存在大量碎片,导致索引扫描效率骤降;
    • 新日期的数据中mark值分布异常(比如大量重复值),使得原本适合旧数据的索引在新数据上完全失效。
  • 缓存未命中:旧日期的查询结果或数据页已经被加载到内存缓存中,查询时直接从内存读取。而新日期的数据还在磁盘上,需要大量磁盘IO操作,耗时剧增。
  • 锁等待冲突:新日期的数据可能还在被其他写入/修改事务占用,你的查询需要等待锁释放,导致长时间卡顿无响应。

内容的提问来源于stack exchange,提问作者Anton Kotikov

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.07.05 01:57:10