必须用数据库级DDL触发器硬拦截，需显式启用、正确解析EVENTDATA()、覆盖TRUNCATE_TABLE事件、RAISERROR级别≥16；默认禁用，OBJECT_NAME()不可靠，须用CAST(EVENTDATA() AS XML).value提取对象名，且必须TRYCATCH包裹以防XML结构变更导致事务中断。
必须用数据库级 DDL 触发器硬拦截，且要显式启用、正确解析 EVENTDATA()、覆盖 TRUNCATE_TABLE 事件、RAISERROR 级别 ≥16 —— 其他方式（如权限控制、关键词过滤）在生产环境都不够可靠。
DDL 触发器默认是禁用的，启用命令不能少
CREATE TRIGGER 后触发器不会自动运行。SQL Server 默认把所有新创建的 DDL 触发器设为 is_disabled = 1。不执行 ENABLE TRIGGER，等于白写。
- 检查是否启用：
SELECT is_disabled FROM sys.triggers WHERE name = 'tr_block_ddl'，返回1就是关着的 - 启用命令（当前库）：
ENABLE TRIGGER tr_block_ddl ON DATABASE - 服务器级触发器要慎用：
ENABLE TRIGGER tr_server_block ON ALL SERVER，它不拦截用户库里的DROP TABLE，只响应CREATE LOGIN这类跨库操作 - 别在
master上建触发器防用户库误删——作用域错，拦截就失效
必须用 EVENTDATA() 提取对象名，OBJECT_NAME() 在 DDL 触发器里返回 NULL
OBJECT_NAME() 在 DDL 触发器中不可靠：表已被删或尚未创建时，它直接返回 NULL。真正可用的是 EVENTDATA() 返回的 XML，里面含 <ObjectName>、<SchemaName>、<DatabaseName> 等字段。
- 正确提取表名：
CAST(EVENTDATA() AS XML).value('(/EVENT_INSTANCE/ObjectName)[1]', 'sysname') - 提取 Schema：
CAST(EVENTDATA() AS XML).value('(/EVENT_INSTANCE/SchemaName)[1]', 'sysname') - 必须用
TRY...CATCH包裹解析逻辑——万一 SQL Server 新版本改了 XML 节点名（比如把ObjectName改成TargetObjectName），没捕获异常会导致整个事务中断，连合法运维都卡住 - 别写错节点名：
ObjectNamee这种拼写错误会让判断永远不生效
TRUNCATE TABLE 必须单独拦截，它不走 DROP 或 ALTER 事件
TRUNCATE TABLE 是独立事件类型，不会触发 DROP_TABLE 或 ALTER_TABLE，漏掉它，就等于给误清空留了后门。
- 触发器里要明确检查：
WHERE @EventType IN ('DROP_TABLE', 'ALTER_TABLE', 'TRUNCATE_TABLE') -
RAISERROR必须 ≥16 级才能中断事务：RAISERROR('Operation blocked', 16, 1)；15 级及以下只会报警告，语句照常执行 - 别用模糊匹配放行临时表：
LIKE '%temp%'可被绕过（比如建user_temp_drop_me）；真要放行，得结合PROGRAM_NAME()判断上下文（如ARCHIVE_JOB）或CONTEXT_INFO()主动申明（如SET CONTEXT_INFO 0x54727573746564） - 不要依赖
ORIGINAL_LOGIN()做白名单——ETL 脚本全用etl_admin账号，那这个账号删任何表都畅通无阻
容易被忽略的兼容性细节
DDL 触发器本身不参与事务，但它抛出的错误会回滚当前批处理。这点在自动化脚本里特别容易踩坑。
- 触发器里禁止查表、调用 UDF 或执行远程查询——DDL 操作期间元数据不稳定，可能引发死锁或超时
- 服务器级触发器无法读取用户库中
DROP INDEX的目标表名，必须靠EVENTDATA()解析，且要确认 XML 中有<TargetObjectName>字段 - 测试时务必用真实账号模拟：用
db_owner测试没问题，不代表db_datawriter权限下也生效——某些事件（如GRANT）对低权账号不触发 - 升级 SQL Server 后，先验证触发器是否仍能正确解析
EVENTDATA()结构，新版可能新增/重命名节点
