DDL触发器必须建在DATABASE级别才能拦截DROP TABLE，通过EVENTDATA()解析事件类型和对象名，用ROLLBACK阻断操作，不可仅靠日志或RAISERROR。
DROP TABLE 操作一旦执行就不可逆，靠事后审计补救成本极高。直接用 DDL 触发器拦截是最有效、最可控的防线。
DDL触发器必须作用于 DATABASE 级别
想拦截 DROP TABLE，触发器不能建在某张表上，而必须绑定到整个数据库。SQL Server 不允许对单个表设置 DROP 类 DDL 触发器——它只响应数据库或服务器级别的事件。
常见错误是写成 CREATE TRIGGER tr_block_drop ON MyTable FOR DROP，这会报错：Incorrect syntax near 'DROP'，因为 DROP 不是 DML 事件，也不被表级触发器支持。
- 正确作用域只能是
ON DATABASE或ON ALL SERVER -
ON DATABASE足够覆盖当前库所有DROP TABLE行为，更安全、权限要求更低 -
ON ALL SERVER会影响整个实例，需sysadmin权限，一般不推荐
用 EVENTDATA() 提取操作类型和对象名
触发器体内部无法直接拿到“要删哪张表”，必须解析 XML 格式的 EVENTDATA()。关键字段包括：
-
/EVENT_INSTANCE/EventType—— 值为DROP_TABLE（注意全大写） -
/EVENT_INSTANCE/ObjectName—— 被删表名（不含 schema，可能只是Users） -
/EVENT_INSTANCE/SchemaName—— 所属 schema（通常是dbo）
示例判断逻辑：
DECLARE @event_type NVARCHAR(100) = EVENTDATA().value('(/EVENT_INSTANCE/EventType)[1]', 'NVARCHAR(100)');
IF @event_type = 'DROP_TABLE'
BEGIN
DECLARE @schema NVARCHAR(128) = EVENTDATA().value('(/EVENT_INSTANCE/SchemaName)[1]', 'NVARCHAR(128)');
DECLARE @object NVARCHAR(128) = EVENTDATA().value('(/EVENT_INSTANCE/ObjectName)[1]', 'NVARCHAR(128)');
IF @schema = 'dbo' AND @object IN ('Config', 'AuditLog', 'UserSettings')
ROLLBACK;
END
必须用 ROLLBACK 阻断，不能只写日志
DDL 触发器默认是 AFTER 触发，意味着语句已执行完毕、对象已被删——此时再记录日志或发邮件都晚了。真正阻止行为，唯一可靠方式是显式 ROLLBACK。
-
ROLLBACK会回滚整个隐式事务，让DROP TABLE失败并报错 - 错误信息类似：
The transaction ended in the trigger. The batch has been aborted. - 不要用
PRINT或RAISERROR替代ROLLBACK，它们不中断执行 - 如果需要提示原因，可用
RAISERROR+ROLLBACK组合，但ROLLBACK必须存在
权限与部署细节容易被忽略
触发器本身运行在调用者上下文中，但能否成功 ROLLBACK 取决于权限链是否完整：
- 创建触发器需
ALTER ANY DATABASE DDL TRIGGER权限（通常db_owner或sysadmin） - 触发器内不能引用不存在的表或视图，否则创建失败；
EVENTDATA()解析失败会静默跳过，建议加TRY...CATCH包裹关键逻辑 - 测试时务必用普通开发账号执行
DROP TABLE，不能只用 sa 账号验证 - 生产环境上线前，先在测试库启用
DISABLE TRIGGER ... ON DATABASE，避免误锁
最易漏的一点：触发器对 tempdb 或内存优化表无效，且无法拦截通过 SSMS 图形界面“删除”动作背后的隐式 DROP——它只捕获显式 T-SQL 语句。
