本文介绍了工作负荷重要性如何影响 Azure Synapse 中专用 SQL 池请求的执行顺序。
业务需求可能需要数据仓库工作负载比其他工作负荷更重要。 请考虑在会计期间关闭之前加载任务关键型销售数据的情况。 其他源（例如天气数据）的数据加载没有严格的 SLA。 将请求加载销售数据的重要性设置为高，将加载天气数据的请求重要性设置为低，这样可以确保销售数据加载优先访问资源并更快完成。
有五个重要性级别：low、below_normal、normal、above_normal 和 high。 对于未设置重要性的请求，将为其分配默认级别 normal。 重要性级别相同的请求具有当前存在的相同计划行为。
除了上述销售数据和天气数据所描述的基本重要性方案之外，还有一些工作负荷重要性有助于满足数据处理和查询需求的方案。
对读取和写入活动的锁进行访问是自然争用的一个方面。 分区切换或 RENAME OBJECT 等操作需要更高级别的锁。 如果没有工作负荷重要性，Azure Synapse 中的专用 SQL 池会针对吞吐量进行优化。 优化吞吐量意味着，当运行请求和排队请求具有相同的锁定需求和资源可用时，排队的请求可以绕过提前到达请求队列的更高锁定需求的请求。 将工作负载重要性应用到具有较高锁定需求的请求后， 将会先运行重要性较高的请求，然后再运行重要性较低的请求。
请看下面的示例：
- Q1 正在主动运行并从 SalesFact 中选择数据。
- Q2 正在排队等待 Q1 完成。 它于上午 9 点提交，并尝试将新数据分区到 SalesFact 中。
- Q3 于上午 9：01 提交，希望从 SalesFact 中选择数据。
如果 Q2 和 Q3 的重要性相同，并且 Q1 仍在执行，Q3 将开始执行。 Q2 将继续等待 SalesFact 上的独占锁。 如果 Q2 的重要性高于 Q3，Q3 将等到 Q2 完成，然后才能开始执行。
另一种情况是，提交具有不同资源类的请求时，重要性可以帮助满足查询需求。 如前所述，在相同的重要性下，Azure Synapse 中的专用 SQL 池针对吞吐量进行了优化。 当混合大小请求（如 smallrc 或 mediumrc）排队时，专用 SQL 池将选择符合可用资源的最早到达请求。 如果应用了工作负载重要性，则计划执行的下一个请求是重要性最高的请求。
请考虑 DW500c 上的以下示例：
- Q1、Q2、Q3 和 Q4 运行 smallrc 查询。
- Q5 是在上午 9:00 提交的，具有 mediumrc 资源类。
- Q6 是在上午 9:01 提交的，具有 smallrc 资源类。
由于 Q5 是 mediumrc，因此需要两个并发槽。 Q5 需要等待两个正在运行的查询完成。 但是，当其中一个正在运行的查询（Q1-Q4）完成后，Q6 会立即被调度，因为有足够的资源来执行该查询。 如果 Q5 的重要性高于 Q6，Q6 将等到 Q5 正在运行，然后才能开始执行。
- 若要详细了解如何创建分类器，请参阅 CREATE WORKLOAD CLASSIFIER (Transact-SQL)。
- 有关工作负荷分类的详细信息，请参阅 工作负荷分类。
- 请参阅快速入门 ：创建工作负荷分类器 ，了解如何创建工作负荷分类器。
- 请参阅有关配置工作负荷重要性和管理和监视工作负荷管理的操作指南文章。
- 参阅 sys.dm_pdw_exec_requests 以查看查询和分配的重要性。