SQL Server 中需在数据库级创建 DDL 触发器（ON DATABASE）捕获 DROP TABLE，不可建于表级；须用大写事件名、WITH EXECUTE AS 'dbo'，并注意 TRUNCATE_TABLE 的权限绕过与日志记录优化。
SQL Server 里怎么写 DROP TABLE 的触发器
sql server 不允许在 master 或用户数据库的系统表上建 ddl 触发器来捕获 drop table，但可以在数据库作用域用 create trigger ... on database 捕获。关键不是“能不能”，而是“在哪建、对谁生效”。
常见错误是直接在目标表上建触发器，结果发现根本不触发——DDL 触发器不能建在表级，必须建在数据库或服务器级。
-
ON DATABASE触发器能捕获当前数据库内所有DROP_TABLE、ALTER_TABLE、TRUNCATE_TABLE等事件 - 触发器本身要建在目标数据库下（比如你想监控
MyAppDB，就得先USE MyAppDB再创建） - 事件名必须用大写全称：
DROP_TABLE、TRUNCATE_TABLE、DROP_PROCEDURE，大小写敏感 - 别忘了加
WITH EXECUTE AS 'dbo'，否则可能因权限不足导致触发器静默失败
TRUNCATE TABLE 为什么比 DROP TABLE 更难拦
TRUNCATE TABLE 不走日志记录行删除，也不触发 DELETE 触发器，但它仍属于 DDL 事件，会被 TRUNCATE_TABLE 事件捕获——前提是触发器已启用且没被绕过。
真正容易漏掉的情况是：有人用 sys.dm_exec_sessions 查到当前会话有 db_owner 权限，就以为能高枕无忧；其实如果触发器里用了 ROLLBACK，而执行者又有 ALTER ANY DATABASE 权限，SQL Server 会跳过触发器直接执行（这是设计行为，不是 bug）。
- 必须显式在触发器里用
IF EVENTDATA().value('(/EVENT_INSTANCE/EventType)[1]', 'nvarchar(128)') = ''TRUNCATE_TABLE''判断类型 -
TRUNCATE_TABLE事件不包含完整 SQL 文本，只能拿到表名和架构名，没法还原原始语句 - 如果数据库设为
RECOVERY SIMPLE，且触发器里做 INSERT 日志，要注意事务日志增长突增
触发器里怎么安全记录操作而不拖慢业务
写日志不能同步塞进主库的审计表，否则一个 DROP TABLE 可能卡住整个数据库。核心思路是“解耦 + 异步 + 最小化”。
- 别在触发器里直接
INSERT INTO dbo.AuditLog，改用sp_audit_write（SQL Server 2016+）或写入tempdb的内存优化表 - 如果必须落盘，优先写到另一个独立数据库（比如
AuditDB），并确保该库恢复模式为Simple - 避免在触发器里调用
EVENTDATA()多次——它每次调用都解析 XML，开销不小；应该只调一次，存进变量再取值 - 别用
PRINT或RAISERROR(..., 10, 1)做提示，它们不会中断执行，还可能被客户端忽略
MySQL / PostgreSQL 用户别硬套 SQL Server 方案
MySQL 根本没有原生 DDL 触发器，CREATE TRIGGER 只支持 INSERT/UPDATE/DELETE；想监控 DROP，只能靠审计插件（如 MySQL Enterprise Audit）或解析 binlog。
PostgreSQL 倒是有 event_trigger，但语法和行为差异很大：它不能 ROLLBACK，只能 RAISE EXCEPTION 中断，且事件名是 ddl_command_start，需自己匹配 pg_event_trigger_ddl_commands() 返回的命令树。
- MySQL 8.0 的
audit_log插件可记录DROP，但默认不开启，且日志格式固定，没法自定义字段 - PostgreSQL 的
event_trigger必须用CREATE EVENT TRIGGER单独建，不能附在函数上，且函数返回类型必须是event_trigger - 三者对
TRUNCATE的处理也不同：SQL Server 当 DDL，MySQL 和 PG 都当 DML（所以 PG 的event_trigger能捕获，MySQL 完全不能）
跨数据库抄代码最危险的地方，是把 EVENTDATA() 当成通用接口——它只存在于 SQL Server，其他系统连函数名都不一样。
