none
TOP导致数据查询非常缓慢的问题 RRS feed

  • 问题

  • 这条语句执行时间将近35秒,这是非常不正常的。

    当我把top的值改成40以上或者把order by 去除,执行计划发生变化,0.01就能查询出来

    数据库版本:2014,请教下是什么原因导致TOP <40会出现这种情况。我已经执行过这三张表的统计信息。UPDATE STATISTICS  WITH FULLSCAN

    2019年12月20日 11:16

答案

  • Hello,

    你的理解是对的,这主要就是SQL Server优化器的问题。

    另外,我也在SQL 2017和SQL 2019上面测试了,这个问题依旧是存在的。

    根据上篇博文的方法,你可以尝试将查询条件列和排序列做成一个复合索引(create index ix_indexName on TableName),可以避免这种情况了,我测试了,的确有效。

    如果此回复对你有用,麻烦'Mark as Answer',十分感谢

    BR

    Dawn Yang


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" 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 MSDNFSF@microsoft.com.

    2019年12月24日 2:52

全部回复

  • 我尝试去除TOP查询的时候也只需要0.01秒,三张表的数据量分别为2万多,正常全表扫描都没这速度慢。是不是sqlserver 2014在这种TOP+ORDER BY DESC组合查询的时候会有BUG,执行计划出现偏差
    2019年12月20日 11:21
  • 你好,

    你这个问题主要是因为SELECT TOP 10的时候,优化器误以为符合条件的数据分布(在整张表中)是均匀的,事实情况下是复合条件的数据分布是不均匀的,优化器采用了非最优化的方式造成的。

    有一份博文和你的问题基本相似,SELECT TOP 1 比不加TOP 1 慢的原因分析以及SELECT TOP 1语句执行计划预估原理,写了原因以及解决方法,应该可以解决你的疑问。

    BR

    Dawn Yang


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" 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 MSDNFSF@microsoft.com.


    2019年12月23日 7:18
  • 你好,

    你这个问题主要是因为SELECT TOP 10的时候,优化器误以为符合条件的数据分布(在整张表中)是均匀的,事实情况下是复合条件的数据分布是不均匀的,优化器采用了非最优化的方式造成的。

    有一份博文和你的问题基本相似,SELECT TOP 1 比不加TOP 1 慢的原因分析以及SELECT TOP 1语句执行计划预估原理,写了原因以及解决方法,应该可以解决你的疑问。

    BR

    Dawn Yang


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" 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 MSDNFSF@microsoft.com.

    TKS,这个问题按我理解就是SQLSERVER优化器不够优化,正常情况优化器不能只按数据量来评估,按我以往对于ORACLE的优化经验来说应该要涉及到多方面,比如数据量、索引碎片、直方图、统计信息等等。我会尝试升级到2016、2017、2019看看这种情况能否有解决,因为这个问题非常影响到生产环境,导致前台应用经常超时


    2019年12月23日 9:58
  • Hello,

    你的理解是对的,这主要就是SQL Server优化器的问题。

    另外,我也在SQL 2017和SQL 2019上面测试了,这个问题依旧是存在的。

    根据上篇博文的方法,你可以尝试将查询条件列和排序列做成一个复合索引(create index ix_indexName on TableName),可以避免这种情况了,我测试了,的确有效。

    如果此回复对你有用,麻烦'Mark as Answer',十分感谢

    BR

    Dawn Yang


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" 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 MSDNFSF@microsoft.com.

    2019年12月24日 2:52
  • Hello,

    你的理解是对的,这主要就是SQL Server优化器的问题。

    另外,我也在SQL 2017和SQL 2019上面测试了,这个问题依旧是存在的。

    根据上篇博文的方法,你可以尝试将查询条件列和排序列做成一个复合索引(create index ix_indexName on TableName),可以避免这种情况了,我测试了,的确有效。

    如果此回复对你有用,麻烦'Mark as Answer',十分感谢

    BR

    Dawn Yang


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" 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 MSDNFSF@microsoft.com.

    将查询条件列和排序列做成一个复合索引,在我的案例中是没有效果的,优化器建议在另一张表上建立索引,我尝试按照优化器建议建立索引,查看执行计划已经是最优的情况,速度是快了,大概查询时间为1.5秒,但是并没有原始不加TOP时0.01秒的速度。我将TOP改成分析函数row_number嵌套的方式,速度也是0.01秒,缺点是代码改写量太大

    2019年12月24日 6:57
  • 你好,

    目前看来还没有进行这方面的优化,你可以到官网提建议,或许后期进行优化:

    如果此回复有用,麻烦”Mark as Answer",十分感谢

    BR 

    Dawn Yang


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" 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 MSDNFSF@microsoft.com.

    2019年12月24日 7:29
  • 你的信息中屏蔽了一些关键信息,比如你的条件和排序到底是落在哪些表上
    执行计划中,到底是那些操作先执行,哪些后执行
    这些统统看不出来了
    2019年12月25日 1:12
  • 太保密,需要各路人马发挥想像力去猜

    top n 是会影响优化器行为,我碰到的案例有:1 -> 100,200 -> 8000


    SQL Server 2016 ~ 2000 性能优化、方案设计 QQ:315054403 田园嘉兴

    2019年12月25日 1:34
  • 你的信息中屏蔽了一些关键信息,比如你的条件和排序到底是落在哪些表上
    执行计划中,到底是那些操作先执行,哪些后执行
    这些统统看不出来了
          留个联系方式,我截图给你
    2019年12月25日 1:45