你猜的没错——确实不存在无需执行「历史表主键不在当前表」这类对比查询，就能直接识别历史表中已从当前表删除行的原生方法。

为什么这么说呢？因为SQL Server 2017和Azure SQL Database本身不会自动维护历史表与当前表之间的“删除关联”。历史表只是存储了某一时刻的数据快照，它和当前表之间没有内置的映射关系来标记哪些行在当前表已经被删掉了。要找出这些行，核心逻辑必然绕不开存在性校验——不管是用NOT EXISTS、LEFT JOIN筛选NULL结果，还是EXCEPT这类集合操作，本质都是在对比两张表的主键（或唯一标识）是否匹配。

不过，如果你想简化后续的查询操作，可以提前做一些架构层面的优化，比如：

• 启用变更数据捕获（CDC）：开启CDC后，数据库会自动记录包括删除在内的所有数据变更，你可以直接从CDC的系统表（比如cdc.[表名]_CT）中获取删除操作的记录，再关联历史表找到对应的行。但这需要提前执行sys.sp_cdc_enable_table来开启CDC，本质上还是依赖系统记录的删除事件来做关联，并非完全脱离对比。
• 采用软删除设计：给当前表添加一个IsDeleted BIT字段，删除操作时不物理删除行，只是将IsDeleted设为1。如果历史表是基于快照生成的，你可以直接通过这个标记来对应已删除的行，但这需要修改表结构，且历史表的生成逻辑也要配合调整。
• 配置删除触发器：在当前表上创建AFTER DELETE触发器，每次删除时将被删除行的主键写入一个专门的“删除日志表”。之后要找历史表中的对应行，直接关联这个日志表即可，不用再做全表对比。但这也是提前做了额外的记录工作，不属于原生的无对比方法。

总的来说：如果不做任何额外的提前配置或架构修改，原生的SQL Server/Azure SQL Database确实没有办法绕过主键对比查询来识别目标行。你的推测完全正确，没有遗漏什么原生的“捷径”。

内容的提问来源于stack exchange，提问作者Randy Minder