我们遇到了一些问题，导致我们无法将本地 SQL 2016 Std Ed 迁移到 Azure SQL 托管实例业务关键层，我想知道是否有人遇到过类似的问题并能为我们提供建议。我们的问题是：
- 最令人头疼的问题是，至少有十几个存储过程和其他查询的查询计划初始编译时间过长（40 秒到 174 秒……我甚至见过长达 725 秒的例子！）。这导致应用程序频繁且随机超时，因为大多数都设置为默认的 30 秒。需要澄清的是，这不是过多的重新编译，而是查询计划中的编译时间非常长。
https://erikdarling.com/are-long-compile-times-bringing-you-down/中的查询和信息对于识别这些查询非常有帮助（我也读过https://littlekendra.com/2024/03/05/long-compilers-who-time-out-not-in-query-store/）。我们也看到了一些编译超时：https://www.brentozar.com/blitzcache/compilation-timeout/。
我们正在尝试调整这些查询并降低其复杂性，因为我们被告知这应该会减少编译时间。几个月来，我们还尝试将 AZ MI 层升级到业务关键层，添加 vCores，并调整实例和数据库设置。
我们已经与 Microsoft 合作了几个星期的 Sev B 案例，并收到了一些提示，但仍然没有解决方案。3 级支持建议确保编译超时查询没有强制计划，因为计划强制允许 SQL 优化器花费比正常时间长 3 倍的时间进行编译，这会增加超时的可能性。唯一强制计划的是自动调整，它仅适用于 MI 的 FORCE_LAST_GOOD_PLAN 选项，请参阅https://learn.microsoft.com/en-us/sql/relational-databases/automatic-tuning/automatic-tuning?view=sql-server-ver16和https://learn.microsoft.com/en-us/azure/azure-sql/database/automatic-tuning-overview?view=azuresql。我们根据他们的建议关闭了 FORCE_LAST_GOOD_PLAN，这有助于解决一些较长的编译时间问题，但不是全部。我们不会使用计划指南 (USE PLAN N'<xml_plan>') 强制执行计划，也不会在查询存储中手动强制执行。他们建议调整查询以降低其复杂性，如果关闭 FORCE_LAST_GOOD_PLAN 不起作用，则运行 DUMP。我希望安排与他们的性能团队进行工作会议来解决这些问题。
更新：在 5 月 28 日与 3 级支持人员通话期间，我们注意到，即使是 SELECT COUNT(*) FROM Table 等一些简单查询也使用了 OptimizationLevel = FULL 而不是 TRIVIAL。3 级支持人员表示，我们无法更改任何设置来影响这一点，但会向产品团队提及此事。
- 与 SQL 2016 Std Ed 中的相同代码相比，我们的分区维护作业（执行 ALTER PARTITION SPLIT）在 MI BusCrit 中的运行时间更长（几天到几周） 。它还会在处理过程中占用数据（和日志）文件中大量额外的使用空间，而这在 SQL 2016 中不会发生，例如在作业运行时，52 GB 的数据库增长到 588 GB！膨胀（和性能？）可能部分与加速数据库恢复 (ADR) 有关，因为它在 SQL 2019+ 和 AZ MI 中：Azure SQL 托管实例与本地 SQL Server 中的表大小（另请参阅https://learn.microsoft.com/en-us/sql/relational-databases/accelerated-database-recovery-concepts?view=sql-server-ver16）。
我们正在审查我们继承的算法，因为它似乎没有遵循https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-partition-function-transact-sql?view=sql-server-ver16中的最佳实践“始终在分区范围的两端保留空分区。保留两端的分区以确保分区拆分和分区合并不会引起任何数据移动。分区拆分发生在开始时，分区合并发生在结束时。避免拆分或合并已填充的分区。拆分或合并已填充的分区可能效率低下。它们效率低下，因为拆分或合并可能会导致多达四倍的日志生成，也可能导致严重的锁定。”但我们很困惑，为什么相同的代码在 MI 中运行时间更长，并且过度膨胀数据文件，而在 SQL 2016 Std Ed 中却没有。
我们考虑的另一个建议是使用 SQL 迁移到 Azure VM，但这将使我们的重新平台启动时间增加数月，以设置、测试和运行此环境，因为我们现在没有任何 Azure VM。我们还必须运行修补、备份等。
非常感谢你的帮助！Mike
感谢您分享这些重要信息。
我们最近在 SQLMI 上遇到了类似的问题，当查询计划自动/手动强制执行时，编译时间过长。我们还为此开了一个 MS 票，他们确认禁用 FORCE_LAST_GOOD_PLAN 在当前阶段查询级别不可用。
根据我的调查，将兼容级别降低到 140，编译时间可以恢复正常，因为上述优化器行为被禁用。
正如您所注意到的，（IO）限制可能会造成严重影响。您需要避免在保存数据的分区中进行分区拆分操作，并准备将新分区添加到空分区中。
关于过多的编译时间：你是否摆弄过（数据库范围的CONFIGURATION）LEGACY_CARDINALITY_ESTIMATION