SQL Server CDC 不提供 DELETE 审计所需用户、时间、应用等上下文，仅记录操作本身；需结合业务层拦截、SQL Server 审计或触发器补全，否则审计无效。
SQL Server CDC 本身不直接提供“审计 DELETE”的语义，它只是如实记录 DELETE 操作产生的变更行；要实现可落地的审计（比如谁、何时、从哪张表删了什么），必须在 CDC 基础上补全上下文和访问控制逻辑——否则你拿到的只是一条带 __$operation = 1 的空壳记录。
为什么 cdc._CT 表里的 DELETE 记录没有用户/时间/应用信息
CDC 的设计目标是轻量、异步、事务日志驱动，它只捕获“发生了什么”，不捕获“谁干的”。__$start_lsn 可映射到 cdc.lsn_time_mapping 得到大致时间戳，但无法还原登录名、主机名、应用程序名或会话 ID。这些信息不在事务日志中持久化，CDC 也就无从获取。
-
__$operation = 1表示该行是被删除的快照，字段值是删除前的完整镜像 -
__$start_lsn是事务提交时的 LSN，需用sys.fn_cdc_map_lsn_to_time()转为近似时间，但存在秒级延迟（取决于 capture job 执行频率） - 所有 CDC 表字段均不含
system_user、host_name()、program_name()等运行时上下文
如何给 DELETE 事件补全审计要素：三类可行路径
不能依赖 CDC 单独完成审计，必须组合其他机制。生产环境推荐按优先级排序如下：
- 在业务层统一拦截：所有 DELETE 必须走存储过程或 API 接口，在执行前写入审计日志表（含
@login_name、@app_name、@ip_address、GETDATE()和被删主键），再调用真实 DELETE。CDC 仅作二次校验或归档备份 - 启用 SQL Server 审计功能（
AUDIT对象）：针对特定表或数据库配置ACTION_TYPE = 'DELETE'的服务器审核规范，它能捕获server_principal_name、client_hostname、application_name等完整上下文，但日志写入文件或安全日志，不可直接 JOIN CDC 表 - 结合 DDL 触发器 + CDC 元数据：对目标表建
ON DELETEDML 触发器，手动插入审计表；但会拖慢事务，且与 CDC 异步机制冲突，不建议在高并发 DELETE 场景使用
读取 DELETE 变更时容易忽略的关键细节
直接查 cdc.fn_cdc_get_all_changes_<capture_instance></capture_instance> 函数返回的 __$operation = 1 行，看似简单，实则有多个隐性陷阱：
- 函数默认只返回
__$start_lsn在指定范围内的变更，若未正确推进from_lsn，可能漏掉已清除的 DELETE 记录（受cdc.cleanup_job清理策略影响） -
__$update_mask对 DELETE 恒为 NULL，不能用于判断列变更，但有人误以为它可用于字段级审计 - 如果源表没主键或唯一索引，CDC 启用会失败（报错
Msg 22830），而 DELETE 审计恰恰最需要靠主键定位被删对象 - Always On 环境下，
cdc.fn_cdc_get_all_changes_*必须在主副本执行——可读副本不包含 CDC 元数据和捕获作业状态，强行在只读副本调用会报Cannot execute as the database principal is not a member of the db_owner role
真正可靠的 DELETE 审计，从来不是靠 CDC 单打独斗；它只是拼图里最底层那块“发生了什么”，上面还得叠上“谁干的”“为什么干”“在哪干的”三层上下文。漏掉任何一层，审计日志就只剩技术痕迹，失去追责价值。
