DDL触发器必须显式启用、作用域正确、用EVENTDATA()安全解析、加TRY...CATCH、结合上下文鉴权，并覆盖TRUNCATE_TABLE等事件，RAISERROR需≥16级才能中断事务。
生产环境不能靠“别手抖”来防误操作，必须用 DDL 触发器硬拦截——但只建触发器不等于安全，漏掉 ENABLE、写错作用域或忽略 EVENTDATA() 解析逻辑，都会让拦截形同虚设。
DDL触发器必须显式启用且作用域选对数据库
SQL Server 默认创建的 DDL 触发器是禁用状态，CREATE TRIGGER 后不执行 ENABLE TRIGGER，它永远不会运行。更常见的是在 master 上建了服务器级触发器，却忘了它不拦截用户数据库里的 DROP TABLE——因为服务器级触发器只响应 ALTER DATABASE、CREATE LOGIN 这类跨库操作。
- 检查是否启用：
SELECT is_disabled FROM sys.triggers WHERE name = 'tr_block_ddl' - 启用命令：
ENABLE TRIGGER tr_block_ddl ON DATABASE（针对当前数据库）或ON ALL SERVER（全局，慎用） - 服务器级触发器无法捕获
DROP INDEX在用户库中的执行——它只看到DROP_INDEX事件，但没权限读取目标表名，需配合EVENTDATA()提取完整上下文
靠 EVENTDATA() 提取真实操作对象，别信 OBJECT_NAME()
OBJECT_NAME() 在 DDL 触发器里返回 NULL，因为对象已被删或尚未创建；真正可用的是 EVENTDATA() 返回的 XML，里面含 <objectname></objectname>、<databasename></databasename>、<schemaname></schemaname> 等字段。解析错一个节点名，比如把 ObjectName 写成 ObjectNamee，整个判断就失效。
- 正确提取表名：
CAST(EVENTDATA() AS XML).value('(/EVENT_INSTANCE/ObjectName)[1]', 'sysname') - 必须加
TRY...CATCH包裹解析逻辑——如果 XML 结构意外变化（如新版 SQL Server 改字段名），未捕获异常会导致触发器直接报错中断事务，反而阻断合法运维 - 别用
LIKE '%temp%'模糊匹配表名放行临时表——攻击者可建user_temp_drop_me绕过
白名单机制要绑定会话上下文，不是靠登录名硬编码
只检查 ORIGINAL_LOGIN() 是危险的：所有归档脚本都用 etl_admin 账号，那这个账号删任何表都畅通无阻。得结合会话标识区分“谁在删”和“为什么删”。
- 优先用
PROGRAM_NAME()：人工操作通常带SQLServerManagementStudio或sqlcmd，归档任务应统一设为ARCHIVE_JOB - 避免依赖
HOST_NAME()：容器化后全是sqlserver-01这类泛化名，不可区分具体实例 - 允许脚本主动申明权限：归档脚本开头执行
SET CONTEXT_INFO 0x54727573746564，触发器里用CONTEXT_INFO()检查，比改账号更灵活
注意 TRUNCATE TABLE 和 DROP 的触发器覆盖差异
TRUNCATE TABLE 不触发 DML 触发器，但会触发 DDL 触发器（事件类型为 TRUNCATE_TABLE）；而 DROP DATABASE 根本不会进任何用户定义的触发器——它绕过所有数据库级逻辑，直接走系统内核路径。
- 必须在 DDL 触发器中显式检查
EVENT_TYPE()是否为'TRUNCATE_TABLE'，否则TRUNCATE仍可清空数据 -
DROP DATABASE只能靠权限控制：回收db_owner对master的ALTER ANY DATABASE权限，或用GRANT CONTROL SERVER替代，缩小高危权限粒度 - DDL 触发器本身不能阻止
RESTORE DATABASE，但可捕获RESTORE_DATABASE事件并抛出错误，强制走审批流程
最易被忽略的点：DDL 触发器里的 RAISERROR 必须用级别 16 以上才能中断事务，级别 10 只算信息性消息；另外，所有解析 EVENTDATA() 的字符串操作都要预判 NULL，否则 .value() 报错会让整个触发器失效，变成“静默放行”。
