我的一个存储过程执行时间太长.看看查询执行计划,我能够找到操作太长时间了.它是一个嵌套循环物理操作符,具有外部表(65991行)和内部表(19223行).在嵌套循环中,显示估计行= 1,268,544,993(乘以65991乘以19223)如下：
我读了一些关于用于连接的物理运算符的文章,并且有点混淆,无论嵌套循环或哈希匹配在这种情况下是否会更好.从我可以收集到的
哈希匹配 – 当没有可用的索引可用时,优化器使用哈希匹配,一个表大大小于其他表,表不会在连接列上排序.散列匹配也可能表示可以使用更有效的连接方法(嵌套循环或合并连接).
问题：在这种情况下,哈希匹配是否比嵌套循环更好？
谢谢
解决方法
绝对.哈希匹配将是一个巨大的进步.然后在较小的19,223行表上创建散列,然后使用65,991行较大的表进行探查,这比使用1,993行的嵌套循环要小得多.
服务器选择嵌套循环的唯一原因是它严重低估了所涉及的行数.您的表格是否有统计数据,如果是,是否定期更新？统计是什么使服务器能够选择好的执行计划.
如果您已经正确处理统计信息,并且仍然有问题,您可以强制它使用如下的HASH连接：
SELECT * FROM TableA A -- The smaller table LEFT HASH JOIN TableB B -- the larger table
请注意,一旦你这样做,它也将强制加入订单.这意味着您必须正确安排所有表,以使其连接顺序有意义.通常,您将检查服务器已具有的执行计划,并更改查询中表的顺序以进行匹配.如果你不熟悉如何做到这一点,基础是每个“左”输入首先,在图形执行计划中,左边的输入是较低的输入.涉及许多表的复杂连接可能必须将连接组合在括号内,或者使用RIGHT JOIN,以使执行计划成为最佳(交换左和右输入,但在连接顺序中的正确点引入表).
通常最好避免使用加入提示并强制加入订单,否则先做其他任何事情.您可以查看表上的索引,碎片,减少列大小(例如使用不需要Unicode的varchar而不是nvarchar),或将查询分割为部分(先插入到临时表,然后加入).
