DDL触发器仅支持ON DATABASE或ON ALL SERVER作用域，必须用FOR而非AFTER或INSTEAD OF；可拦截显式ALTER TABLE但无法阻止高权限用户绕过，且不响应SSMS图形操作和sp_rename等系统存储过程调用。
不能完全禁止，但能拦截绝大多数显式 ALTER TABLE 操作；高权限用户仍可绕过，必须配合权限控制才有效。
DDL触发器必须建在 DATABASE 级别
建在表上或用 AFTER ALTER_TABLE 都无效——SQL Server 的 DDL 触发器只支持 ON DATABASE 或 ON ALL SERVER 作用域，且语法中只能用 FOR（不是 AFTER 或 INSTEAD OF）。
- 错误写法：
CREATE TRIGGER tr ON users FOR ALTER_TABLE→ 报错：无法在对象上创建 DDL 触发器 - 正确写法：
CREATE TRIGGER tr_prevent_alter ON DATABASE FOR ALTER_TABLE - 触发器不会出现在
sys.objects中，查状态要用：SELECT name, is_disabled FROM sys.triggers WHERE parent_class = 0（parent_class = 0表示数据库级）
EVENTDATA() 提取对象名要小心 XML 路径和类型转换
EVENTDATA() 返回 XML，直接用 .value() 提取时，字段名大小写敏感、路径错一位就返回 NULL，且类型不匹配会报错。
- 提取被修改的表名：
EVENTDATA().value('(/EVENT_INSTANCE/ObjectName)[1]', 'sysname')（注意括号和索引） - 提取数据库名（用于过滤 tempdb）：
EVENTDATA().value('(/EVENT_INSTANCE/DatabaseName)[1]', 'sysname') - 不要写成
'nvarchar(128)'——SQL Server 2016+ 推荐用sysname，否则可能截断长名 - 如果路径不存在（比如某些系统操作没填
ObjectName），.value()返回 NULL，需加IS NULL判断再做逻辑
ROLLBACK 能中断操作，但对高权限用户无效
ROLLBACK 在触发器里确实能回滚当前 DDL 事务，让 ALTER TABLE 失败，但它拦不住拥有 CONTROL、ALTER ANY TABLE 或 db_owner 角色的用户。
- 这类用户执行
DISABLE TRIGGER tr_prevent_alter ON DATABASE后，触发器彻底不运行 - 他们还能直接删掉触发器：
DROP TRIGGER tr_prevent_alter ON DATABASE - 所以必须同步回收权限：
REVOKE ALTER ANY TABLE TO [app_user]，并确保触发器由低权限账号（如ddl_monitor）创建 - 别依赖
RAISERROR+ROLLBACK就以为万事大吉——它只是第一道门，不是锁
SSMS 图形界面和 sp_rename 不触发 DDL 触发器
这是最容易被忽略的绕过点：SQL Server Management Studio 改列名、改类型、加约束时，底层调用的是 sp_rename 或其他系统存储过程，不走标准 ALTER TABLE 语法路径，因此 FOR ALTER_TABLE 触发器完全不响应。
- 例如在 SSMS 中右键表 → “设计”，改一列数据类型 → 不触发
ALTER_TABLE事件 -
sp_rename 'users.name', 'full_name', 'COLUMN'同样不触发 - 想覆盖这部分，得额外监听
RENAME事件组（SQL Server 2016+ 支持），或用服务器级触发器捕获sp_rename调用（但开销大、易误杀） - 更现实的做法是禁用图形化工具入口，或审计日志中重点盯
sp_rename的调用来源
真正起效的防护从来不是单靠一个 ROLLBACK，而是把触发器当哨兵，把权限当门锁，把 DDL 审计当监控录像——三者缺一不可。尤其要注意 sp_rename 和图形界面这种“合法但隐身”的操作路径，它们才是生产环境里最常被漏掉的缺口。
