相关疑难解决方法(0)

这可能属于意见范畴，但我很好奇人们是否使用跟踪标志 4199作为 SQL Server 的启动参数。对于使用过它的人，您在什么情况下遇到过查询回归？

这似乎是全面的潜在性能优势，我正在考虑在我们的非生产环境中全局启用它，并让它静置几个月以找出任何问题。

2014 年（或 2016 年）是否默认将 4199 中的修复程序纳入优化器？虽然我理解不引入意外计划更改的情况，但在版本之间隐藏所有这些修复似乎很奇怪。

我们使用的是 2008、2008R2，主要是 2012。

概要：如果逻辑树中较早存在未消除的外连接，则可以逻辑消除的内连接将被保留。为什么？

示例在 AdventureWorks2008R2 及更高版本中运行。我添加了跟踪标志来提供连续树和规则的整体上下文。

第一个例子，对于上下文：

• Product在简化过程中消除了左连接（连接表中不需要数据并且引用的值是唯一的）。
• SalesOrderDetail然后在连接崩溃期间消除内部连接，即启发式连接重新排序（连接表中不需要数据，引用者不可为空，并且强制执行 FK）

SELECT sod.SalesOrderDetailID
FROM Sales.SalesOrderDetail AS sod
    LEFT JOIN Production.Product AS p -- Eliminated during simplification (Rule: RedundantLOJN)
        ON p.ProductID = sod.ProductID
    JOIN Sales.SalesOrderHeader AS soh -- Eliminated during join collapse. (Annotated by TF 8619)
        ON soh.SalesOrderID = sod.SalesOrderID
OPTION (RECOMPILE, QUERYTRACEON 8619, QUERYTRACEON 8621, QUERYTRACEON 8606, QUERYTRACEON 3604);

然而，在第二个示例中，可以从逻辑上消除与 SalesOrderHeader 的连接，但事实并非如此。

• 保留左连接，因为需要来自 的数据Product。在逻辑树中，此连接被定义为在不消除的连接之前。
• 后续的加入SalesOrderHeader可以在逻辑上被消除，因为先前的加入不能使消除要求无效：非空引用 + FK 完整性。

SELECT p.Name
FROM …