只建 FOR DROP_TABLE 触发器不够，必须显式启用、用 EVENTDATA() 提取真实对象名、加 TRY...CATCH 防解析失败，并覆盖 TRUNCATE_TABLE 事件，否则删表仍可能成功。
直接结论：只建 FOR DROP_TABLE 触发器不够，必须显式启用、用 EVENTDATA() 提取真实对象名、加 TRY...CATCH 防解析失败，并覆盖 TRUNCATE_TABLE 事件——否则删表仍可能成功。
触发器建了但不生效？检查是否启用和作用域
SQL Server 创建 DDL 触发器后默认是禁用状态，CREATE TRIGGER 不等于“立刻拦截”。常见疏漏包括：
- 忘记执行
ENABLE TRIGGER tr_block_drop ON DATABASE，导致触发器始终不运行 - 在
master库建了服务器级触发器（ON ALL SERVER），但它对用户库中的DROP TABLE无响应——服务器级触发器只捕获CREATE LOGIN、ALTER DATABASE等跨库事件 - 误以为触发器会自动作用于所有数据库，实际必须在目标生产库上下文中创建并启用
验证方式：SELECT name, is_disabled FROM sys.triggers WHERE parent_class = 0 AND type = 'TR'（parent_class = 0 表示数据库级）
为什么 OBJECT_NAME() 返回 NULL？必须用 EVENTDATA() 解析 XML
在 DROP_TABLE 触发器中调用 OBJECT_NAME() 总是返回 NULL，因为对象已被删除或尚未存在。真正可用的是 EVENTDATA() 返回的 XML：
- 正确提取表名：
CAST(EVENTDATA() AS XML).value('(/EVENT_INSTANCE/ObjectName)[1]', 'sysname') - 提取 Schema 名：
CAST(EVENTDATA() AS XML).value('(/EVENT_INSTANCE/SchemaName)[1]', 'sysname') - 节点名大小写敏感，
/ObjectName写成/objectname或/ObjectNamee就会取不到值 - 必须包裹在
TRY...CATCH中——新版 SQL Server 若调整 XML 结构（如字段重命名），未捕获异常会导致触发器报错中断事务，反而阻断合法运维
TRUNCATE TABLE 能绕过 DROP_TABLE 触发器？必须单独监听
TRUNCATE TABLE 不触发 DROP_TABLE 事件，它对应独立事件 TRUNCATE_TABLE。攻击者或误操作常用它清空关键表，且权限要求更低（不需要 ALTER 权限，只需 INSERT/DELETE）。所以触发器事件列表必须显式包含：
FOR DROP_TABLE, TRUNCATE_TABLE, ALTER_TABLE- 若还要防索引误删，得额外加
DROP_INDEX；注意服务器级触发器无法读取用户库中被删索引的表名，必须在数据库级触发器里解析EVENTDATA() -
ROLLBACK是必须的，仅PRINT或RAISERROR不足以终止操作；错误级别需 ≥16 才能中断事务，例如RAISERROR('Blocked', 16, 1)
如何区分人工误删和归档脚本？靠 PROGRAM_NAME() + CONTEXT_INFO()
硬拦所有 DROP 会卡住归档任务。不能只靠登录名（ORIGINAL_LOGIN()），因为 ETL 脚本和 DBA 都可能用同一个账号。更可靠的方式是结合会话上下文：
- 人工操作通常带
PROGRAM_NAME()如Microsoft SQL Server Management Studio、sqlcmd；归档作业应统一设为ARCHIVE_JOB - 允许脚本主动申明可信身份：
SET CONTEXT_INFO 0x54727573746564（ASCII “Trusted”），触发器中用CONTEXT_INFO()检查 - 避免用
HOST_NAME()——容器化部署下全是sqlserver-01这类泛化名，无法区分具体实例或任务
复杂点在于：哪怕触发器逻辑完美，高权限用户仍可执行 DISABLE TRIGGER ... ON users 直接绕过——所以必须回收 ALTER TABLE 权限，不能让运维账号同时拥有 db_owner 和触发器管理权。
