如何最好地处理这个执行计划
How to best approach this execution plan
我们的仓库管理包存在存储过程瓶颈（众多瓶颈之一），主要的减速是由于生成此执行计划的查询。
https://www.brentozar.com/pastetheplan/?id=HkNg65elP
存储过程可能需要 3 到 10 秒到 运行，这在其 运行 所在的业务流程上下文中相当慢。
一些附加信息：是的，有一个 table 正在执行完整的 table 扫描，但是这个 table 很窄，只有 76 行。查询进行了一些左连接和一些排序，这是产生正确的最高结果所必需的。总的来说，它有点像“Rube Goldberg”类型的查询，可能会被简化，但我的目标是看看是否有可能帮助建立一些索引（我已经完成了，它有点帮助）甚至一些如果需要，对查询进行小的调整。
最后，我需要根据计划知道接下来的重点。
这里是查询：
SELECT TOP 1 loc.location_id, loc.wh_id
FROM t_item_uom itu WITH (NOLOCK)
INNER JOIN t_class_loca clc WITH (NOLOCK)
ON itu.wh_id = clc.wh_id
AND ISNULL(dbo.usf_get_item_class_dia_ovrd ('13098271', '895', itu.uom, NULL), itu.class_id) = clc.class_id
INNER JOIN t_location loc WITH (NOLOCK)
ON clc.wh_id = loc.wh_id
AND clc.location_id = loc.location_id
INNER JOIN t_pick_area pka WITH (NOLOCK)
ON pka.pick_area = loc.pick_area
AND pka.wh_id = loc.wh_id
AND (pka.pick_area <> N'LABEL' OR (pka.pick_area = N'LABEL' AND 0 IS NULL AND 0 IS NULL) )
AND (pka.pick_area_type = 'R' OR (pka.pick_area_type = 'V' and 0 IS NULL) )
INNER JOIN t_zone_loca zlc WITH (NOLOCK)
ON loc.wh_id = zlc.wh_id
AND loc.location_id = zlc.location_id
INNER JOIN (
SELECT loc.wh_id, loc.pnd_location_id --, loc.location_id
FROM t_location loc with (nolock)
inner join t_class_loca clc WITH (NOLOCK)
on clc.location_id = loc.location_id
and clc.wh_id = loc.wh_id
and clc.class_id = 'APPAREL'
LEFT JOIN t_stored_item sto with (nolock)
ON sto.put_away_location = loc.location_id
AND sto.wh_id = loc.wh_id --BTH 20160907 missing wh_id
AND sto.put_away_location IS NOT NULL
AND sto.type = 0
WHERE loc.type in ('I','M')
AND loc.pnd_location_id IS NOT NULL --BTH 20160907 - remove from having clause, add here
GROUP BY loc.wh_id, loc.pnd_location_id, loc.c3
HAVING ((COUNT(sto.hu_id) < 100
and loc.pnd_location_id IS NOT NULL --BTH 201600907
and c3 is null)
OR (COUNT(sto.hu_id) < 500 --and loc.pnd_location_id IS NOT NULL --BTH 201600907
and c3 = 'BULK'))
) as pnd
ON pnd.wh_id = loc.wh_id
AND pnd.pnd_location_id = loc.pnd_location_id
LEFT OUTER JOIN t_put_rules_empty_and_unalloc_locs_by_pnd tpr WITH (NOLOCK)
ON tpr.pnd_location_id = loc.pnd_location_id
AND tpr.class_id = itu.class_id
AND tpr.wh_id = loc.wh_id
LEFT OUTER JOIN t_work_q q WITH(NOLOCK)
ON q.location_id = loc.location_id
AND q.wh_id = loc.wh_id
AND q.work_type = '08'
AND q.work_status = 'U'
WHERE loc.status = 'E'
AND ISNULL(q.work_q_id, 0) = 0
AND ( loc.c3 is null or loc.c3 not in ('R','H','S'))
AND (
(
loc.type = 'M'
AND ( (SELECT TOP 1 max_sku_count
FROM t_zone zone2 (NOLOCK)
WHERE zone2.wh_id = loc.wh_id
AND loc.zone = zone2.zone) >
(SELECT COUNT(sto2.item_number)
FROM t_stored_item sto2 (NOLOCK)
WHERE loc.wh_id = sto2.wh_id
AND loc.location_id = sto2.location_id
)
OR '13098271' IN (SELECT sto2.item_number
FROM t_stored_item sto2 (NOLOCK)
WHERE loc.wh_id = sto2.wh_id
AND loc.location_id = sto2.location_id
)
)
)
OR (loc.type = 'I' AND itu.unit_volume = 0 AND itu.nested_volume = 0)
OR (loc.type = 'I' AND loc.capacity_volume = 0)
OR (loc.type = 'I' AND loc.capacity_volume >= 0 +
(CASE
WHEN 0 = 0 THEN 0
ELSE 0
END * (1 - 1)
)
)
)
--Ensure that only one item is designated to the location
AND (loc.type = 'M'
OR (loc.type = 'I' AND NOT EXISTS (SELECT 1
FROM t_stored_item sto2 WITH (NOLOCK) -- Sum the item in the location to determine volume
WHERE sto2.wh_id = loc.wh_id
AND sto2.put_away_location = loc.location_id)))
AND itu.wh_id = '895'
AND itu.item_number = '13098271'
AND clc.class_id = 'APPAREL'
AND zlc.zone = 'ALL'
ORDER BY
tpr.percent_empty_and_unalloc DESC,
loc.type,
loc.user_count,
loc.picking_flow,
loc.location_id
在不知道您的表和数据的结构的情况下，我的建议是查看执行成本较高的部分。在您的示例中，这将位于右上角：分别为 14%（内部连接）、17% 和 22%，+ 19% 和 25% 其他地方。
其他重要的事情：您的 索引 以及它们是否按应有的方式使用。我觉得不是。
关注 25%（Key Lookup (Clustered)）：这 link 可能会帮助您更好地理解问题（并省去冗长的解释）。同样，我不知道你的表的结构。但是我觉得你的索引在这里不够。
我看到了这个：CONVERT_IMPLICIT(nvarchar(4000)。这是什么 ？会不会降低性能？
如果表的结构不好并且数据模型错误，那么优化起来会更加困难。添加更多索引或改写查询并不总是解决方案。
基于快速浏览您的执行计划。根据成本，第 1 期和第 3 期将为您提供最佳投资回报率。
第一期：Key Lookup
在您的索引 IDX_wh_id_status_pnd_location_id 中，您的索引的 INCLUDE 部分缺少列 zone。
简而言之：您正在比较不同类型的列。确保比较相同类型的列。如果这些是外键列，则两个表中的类型应该完全相同。如果它们是参数，请更改类型或 cast/covert 它们。
第三期：聚合
您在 [t_stored_item].[sto].put_away_location 上有一个聚合（最大值、计数、平均值...），行估计值为 129108。
尝试创建一个 indexed view for this part of the query with the aggregation in the indexed view. Use the indexed view instead. More info
估计也与实际相差甚远，您可以尝试重建统计数据，但可能无济于事。为什么？ Read this
第四期：用户自定义函数
您有一个 INNER JOIN usf_get_item_class_dia_ovrd 是否可以内联编写用户定义函数的逻辑？当我们在内联时，代码通常会被优化，现在标量函数正在逐行执行而不是基于集合。
第五期：常量扫描-实际行数0
这可能不是什么大问题，但当表达式相互抵消时，通常会发生这种情况。虚拟示例：1 = 0 将始终评估为 0 行，因此 SQL 服务器将其替换为空常量扫描。
在复杂的查询中，您可能无法立即找到它。这不会对性能产生很大影响，但是当您从查询中删除这些时，您可能会获得更好的执行计划。
如果有兴趣观看 this video 以更好地了解查询优化器。 （有点旧，但仍然相关）
奖励：参数嗅探
您提到它是一个存储过程。存储过程通常有 parameters sniffing.
的问题
我们的仓库管理包存在存储过程瓶颈（众多瓶颈之一），主要的减速是由于生成此执行计划的查询。
https://www.brentozar.com/pastetheplan/?id=HkNg65elP
存储过程可能需要 3 到 10 秒到 运行，这在其 运行 所在的业务流程上下文中相当慢。
一些附加信息：是的，有一个 table 正在执行完整的 table 扫描，但是这个 table 很窄，只有 76 行。查询进行了一些左连接和一些排序，这是产生正确的最高结果所必需的。总的来说，它有点像“Rube Goldberg”类型的查询，可能会被简化，但我的目标是看看是否有可能帮助建立一些索引（我已经完成了，它有点帮助）甚至一些如果需要，对查询进行小的调整。
最后，我需要根据计划知道接下来的重点。
这里是查询：
SELECT TOP 1 loc.location_id, loc.wh_id
FROM t_item_uom itu WITH (NOLOCK)
INNER JOIN t_class_loca clc WITH (NOLOCK)
ON itu.wh_id = clc.wh_id
AND ISNULL(dbo.usf_get_item_class_dia_ovrd ('13098271', '895', itu.uom, NULL), itu.class_id) = clc.class_id
INNER JOIN t_location loc WITH (NOLOCK)
ON clc.wh_id = loc.wh_id
AND clc.location_id = loc.location_id
INNER JOIN t_pick_area pka WITH (NOLOCK)
ON pka.pick_area = loc.pick_area
AND pka.wh_id = loc.wh_id
AND (pka.pick_area <> N'LABEL' OR (pka.pick_area = N'LABEL' AND 0 IS NULL AND 0 IS NULL) )
AND (pka.pick_area_type = 'R' OR (pka.pick_area_type = 'V' and 0 IS NULL) )
INNER JOIN t_zone_loca zlc WITH (NOLOCK)
ON loc.wh_id = zlc.wh_id
AND loc.location_id = zlc.location_id
INNER JOIN (
SELECT loc.wh_id, loc.pnd_location_id --, loc.location_id
FROM t_location loc with (nolock)
inner join t_class_loca clc WITH (NOLOCK)
on clc.location_id = loc.location_id
and clc.wh_id = loc.wh_id
and clc.class_id = 'APPAREL'
LEFT JOIN t_stored_item sto with (nolock)
ON sto.put_away_location = loc.location_id
AND sto.wh_id = loc.wh_id --BTH 20160907 missing wh_id
AND sto.put_away_location IS NOT NULL
AND sto.type = 0
WHERE loc.type in ('I','M')
AND loc.pnd_location_id IS NOT NULL --BTH 20160907 - remove from having clause, add here
GROUP BY loc.wh_id, loc.pnd_location_id, loc.c3
HAVING ((COUNT(sto.hu_id) < 100
and loc.pnd_location_id IS NOT NULL --BTH 201600907
and c3 is null)
OR (COUNT(sto.hu_id) < 500 --and loc.pnd_location_id IS NOT NULL --BTH 201600907
and c3 = 'BULK'))
) as pnd
ON pnd.wh_id = loc.wh_id
AND pnd.pnd_location_id = loc.pnd_location_id
LEFT OUTER JOIN t_put_rules_empty_and_unalloc_locs_by_pnd tpr WITH (NOLOCK)
ON tpr.pnd_location_id = loc.pnd_location_id
AND tpr.class_id = itu.class_id
AND tpr.wh_id = loc.wh_id
LEFT OUTER JOIN t_work_q q WITH(NOLOCK)
ON q.location_id = loc.location_id
AND q.wh_id = loc.wh_id
AND q.work_type = '08'
AND q.work_status = 'U'
WHERE loc.status = 'E'
AND ISNULL(q.work_q_id, 0) = 0
AND ( loc.c3 is null or loc.c3 not in ('R','H','S'))
AND (
(
loc.type = 'M'
AND ( (SELECT TOP 1 max_sku_count
FROM t_zone zone2 (NOLOCK)
WHERE zone2.wh_id = loc.wh_id
AND loc.zone = zone2.zone) >
(SELECT COUNT(sto2.item_number)
FROM t_stored_item sto2 (NOLOCK)
WHERE loc.wh_id = sto2.wh_id
AND loc.location_id = sto2.location_id
)
OR '13098271' IN (SELECT sto2.item_number
FROM t_stored_item sto2 (NOLOCK)
WHERE loc.wh_id = sto2.wh_id
AND loc.location_id = sto2.location_id
)
)
)
OR (loc.type = 'I' AND itu.unit_volume = 0 AND itu.nested_volume = 0)
OR (loc.type = 'I' AND loc.capacity_volume = 0)
OR (loc.type = 'I' AND loc.capacity_volume >= 0 +
(CASE
WHEN 0 = 0 THEN 0
ELSE 0
END * (1 - 1)
)
)
)
--Ensure that only one item is designated to the location
AND (loc.type = 'M'
OR (loc.type = 'I' AND NOT EXISTS (SELECT 1
FROM t_stored_item sto2 WITH (NOLOCK) -- Sum the item in the location to determine volume
WHERE sto2.wh_id = loc.wh_id
AND sto2.put_away_location = loc.location_id)))
AND itu.wh_id = '895'
AND itu.item_number = '13098271'
AND clc.class_id = 'APPAREL'
AND zlc.zone = 'ALL'
ORDER BY
tpr.percent_empty_and_unalloc DESC,
loc.type,
loc.user_count,
loc.picking_flow,
loc.location_id
在不知道您的表和数据的结构的情况下，我的建议是查看执行成本较高的部分。在您的示例中，这将位于右上角：分别为 14%（内部连接）、17% 和 22%，+ 19% 和 25% 其他地方。
其他重要的事情：您的 索引 以及它们是否按应有的方式使用。我觉得不是。
关注 25%（Key Lookup (Clustered)）：这 link 可能会帮助您更好地理解问题（并省去冗长的解释）。同样，我不知道你的表的结构。但是我觉得你的索引在这里不够。
我看到了这个：CONVERT_IMPLICIT(nvarchar(4000)。这是什么 ？会不会降低性能？
如果表的结构不好并且数据模型错误，那么优化起来会更加困难。添加更多索引或改写查询并不总是解决方案。
基于快速浏览您的执行计划。根据成本，第 1 期和第 3 期将为您提供最佳投资回报率。
第一期：Key Lookup
在您的索引 IDX_wh_id_status_pnd_location_id 中，您的索引的 INCLUDE 部分缺少列 zone。
简而言之：您正在比较不同类型的列。确保比较相同类型的列。如果这些是外键列，则两个表中的类型应该完全相同。如果它们是参数，请更改类型或 cast/covert 它们。
第三期：聚合
您在 [t_stored_item].[sto].put_away_location 上有一个聚合（最大值、计数、平均值...），行估计值为 129108。
尝试创建一个 indexed view for this part of the query with the aggregation in the indexed view. Use the indexed view instead. More info
估计也与实际相差甚远，您可以尝试重建统计数据，但可能无济于事。为什么？ Read this
第四期：用户自定义函数
您有一个 INNER JOIN usf_get_item_class_dia_ovrd 是否可以内联编写用户定义函数的逻辑？当我们在内联时，代码通常会被优化，现在标量函数正在逐行执行而不是基于集合。
第五期：常量扫描-实际行数0
这可能不是什么大问题，但当表达式相互抵消时，通常会发生这种情况。虚拟示例：1 = 0 将始终评估为 0 行，因此 SQL 服务器将其替换为空常量扫描。
在复杂的查询中，您可能无法立即找到它。这不会对性能产生很大影响，但是当您从查询中删除这些时，您可能会获得更好的执行计划。
如果有兴趣观看 this video 以更好地了解查询优化器。 （有点旧，但仍然相关）
奖励：参数嗅探
您提到它是一个存储过程。存储过程通常有 parameters sniffing.
的问题