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 DELETE DML 触发器，手动插入审计表；但会拖慢事务，且与 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 单打独斗；它只是拼图里最底层那块“发生了什么”，上面还得叠上“谁干的”“为什么干”“在哪干的”三层上下文。漏掉任何一层，审计日志就只剩技术痕迹，失去追责价值。