这更像是一个一般性问题，但这个问题的动机是我在使用 SQL Server 时遇到的一个问题。

我将此触发器附加到包含一些逻辑的表上的 Insert 事件，作为副作用，如果没有插入行，则会引发错误。经过进一步调查，我发现尽管没有插入行，但触发器仍在触发。

Microsoft Docs on DML Triggers 中使用的语言似乎与此行为相矛盾：

DML 触发器是一种特殊类型的存储过程，当发生影响触发器中定义的表或视图的 DML 事件时，它会自动生效。

这是跨 DBMS 的默认行为吗？当没有行受到影响时，是否有特殊原因触发触发器？

假设您有以下表结构：

LogId | ProductId | FromPositionId | ToPositionId | Date                 | Quantity
-----------------------------------------------------------------------------------
1     | 123       | 0              | 10002        | 2018-01-01 08:10:22  | 5
2     | 123       | 0              | 10003        | 2018-01-03 15:15:10  | 9
3     | 123       | 10002          | 10004        | 2018-01-07 21:08:56  | 3
4     | 123       | 10004          | 0            | 2018-02-09 10:03:23  | 1

FromPositionId并且ToPositionId是股票头寸。某些位置 ID:s 具有特殊含义，例如0。事件 from 或 to0表示库存已创建或删除。From0可能是交货的库存，to0可能是发货的订单。

该表目前包含大约 550 …

以下是查询存储遇到的性能问题的简化：

CREATE TABLE #tears
(
    plan_id bigint NOT NULL
);

INSERT #tears (plan_id) 
VALUES (1);

SELECT
    T.plan_id
FROM #tears AS T
LEFT JOIN sys.query_store_plan AS QSP
    ON QSP.plan_id = T.plan_id;

该plan_id列被记录为 的主键sys.query_store_plan，但执行计划并不像预期的那样使用连接消除：

1. DMV 没有投射任何属性。
2. DMV 主键plan_id不能复制临时表中的行
3. 使用了 A LEFT JOIN，因此无法T消除from中的任何行。

执行计划

为什么会这样，在这里可以做些什么来消除连接？

语境

我偶然发现了 SQL Azure 中的一个问题，其中Sort-operator 由于行估计不佳而溢出到 TempDB 中。

• 我们正在查询与多个明细表连接的主表
• 该表使用TenantId-column 对每个租户的表进行分区
• 有些租户有 10,000 行，有些只有 100 行。
• 有一个行级安全策略，可以为FILTER PREDICATE上述所有查询添加一个TenantId
• 查询由 .NET 应用程序中的实体框架生成
• 所有索引统计数据都是最新的
• 所有明细表行都通过Index Seeks检索

问题

由于租户之间的行数差异很大，基数估计器产生的估计值非常低。这与两个内部连接相结合，进一步减少了估计，使得实际产生 3600 行的查询预计只产生 3。这是 3 个数量级的下降。

我尝试了什么？

1. Filtered Statistics为那些产生大量行的键值定义，作为对 CE 的额外提示。
2. 在处理参数化查询时遇到了限制。这OPTION ( RECOMPILE )适用于某些谓词，但不适用于TenantId通过上述安全策略注入的谓词。
3. 内联过滤器谓词，因此我们在同一列上有效过滤两次有效，但似乎......至少可以说是多余的
4. 将INNER JOINs更改为s 可以LEFT OUTER JOIN改善错误连接估计，但由于我们使用实体框架，我更喜欢不需要更改查询的解决方案。注意：显然，如果唯一的方法是重写查询，那么这就是我们将要走的路线。

其他想法

• 我曾考虑过添加一个包含 10 万条记录的虚拟租户来抵消估计值的想法，这样行估计值至少对于最大的真实租户来说足够大，但这会使我们对小租户的估计过高。

我在寻找什么？

• 我做错了什么 - 我把自己画到了一个角落里吗？
• 有没有我可以考虑的替代方案？

我欢迎您的任何想法，谢谢！

排序运算符用于分页。我实际上不想检索所有行。所以简而言之，排序需要发生在数据库中（而不是在应用程序中）。

另外，要明确的是，这里的问题不是 EF 生成的查询。这是一个简单的查询，带有许多INNER/ …

在 SQL Server 中，Except运算符如何在幕后工作的内部算法是什么？它是否在内部获取每一行的哈希值并进行比较？

David Lozinksi 进行了一项研究，SQL：在不存在新记录的地方插入新记录的最快方法他表明，对于大量行，Except 语句是最快的；与我们下面的结果密切相关。

假设：我认为 Left join 会最快，因为它只比较 1 列，Except 花费的时间最长，因为它必须比较所有列。
有了这些结果，现在我们的想法是，Except 自动并在内部获取每一行的哈希值？我查看了除非执行计划，它确实使用了一些哈希。

背景：我们的团队正在比较两个堆表。表 A 不在表 B 中的行被插入到表 B 中。

堆表（来自旧文本文件系统）没有主键/guids/标识符。有些表有重复的行，所以我们找到每一行的Hash，并去除重复，并创建主键标识符。

1）首先我们运行一个except语句，排除（哈希列）

select * from TableA
Except
Select * from TableB,

2）然后我们在HashRowId上的两个表之间运行左连接比较

select * 
FROM dbo.TableA A
left join dbo.TableB B
    on A.RowHash =  B.RowHash
where B.Hash is null

令人惊讶的是，Except Statement Insert 是最快的。

结果实际上与 David Lozinksi 的测试结果接近