SQL Server DDL触发器不支持按用户过滤，必须在触发器开头用ORIGINAL_LOGIN()判断并RETURN；它仅作用于数据库或服务器级，无法绑定用户，且不能访问inserted/deleted表，元数据需解析EVENTDATA() XML。
SQL Server 的 DDL 触发器本身不支持「按登录用户过滤」的原生语法，CREATE TRIGGER 语句中没有 FOR USER 或类似参数。所谓“只对特定用户生效”，必须在触发器内部手动判断当前执行者，并用 RETURN 提前退出。
DDL 触发器无法直接绑定到用户
DDL 触发器的作用域只有两个：数据库级（ON DATABASE）或服务器级（ON ALL SERVER），它不接受 ON USER、ON LOGIN 或任何用户粒度的限定。即使你用 EXECUTE AS 'user_name' 指定了执行上下文，那也只是影响触发器内语句的权限，不是触发条件。
- 触发器一旦创建，所有能执行对应 DDL 语句的用户（如拥有
ALTER ANY DATABASE权限的人）都会触发它 -
EVENTDATA()只能读取事件发生时的上下文，不能阻止事件本身被提交（除非显式ROLLBACK） - 试图靠
IF SUSER_NAME() NOT IN ('admin', 'deploy')外层包住整个逻辑是常见做法，但必须写在触发器主体开头
用 SUSER_NAME() 和 ORIGINAL_LOGIN() 做运行时拦截
真正起作用的是在触发器体第一行就检查调用者身份，不符合条件就 RETURN —— 注意不是 RAISERROR + RETURN，否则仍会记录日志甚至引发客户端异常；如果只是想静默跳过，直接 RETURN 最安全。
-
SUSER_NAME()返回当前会话的安全标识符对应的登录名（如'DOMAIN\alice'） -
ORIGINAL_LOGIN()更可靠，它不受EXECUTE AS切换影响，始终返回最初建立连接的登录名 - 不要用
USER_NAME()，它查的是数据库用户，不是登录主体，容易误判 - 示例片段：
IF ORIGINAL_LOGIN() NOT IN ('sa', 'DEPLOY_USER') RETURN;
小心权限提升和递归触发风险
哪怕加了用户校验，仍可能被绕过：比如高权限账号执行 EXECUTE AS 后再跑 DDL，或者通过代理作业、SQL Agent job 启动的会话会以作业所有者身份运行。
- 若需更严格控制，应配合权限收窄：收回普通用户的
ALTER DATABASE等权限，只允许通过预设存储过程变更结构 - DDL 触发器自身若执行了其他 DDL（如自动备份 schema），可能再次触发自己，导致无限递归 —— 记得加
IF (SELECT TRIGGER_NESTLEVEL()) > 1 RETURN - 服务器级触发器（
ON ALL SERVER）影响面极大，测试务必在隔离实例进行，上线前确认不会阻断 DBA 日常维护操作
最易被忽略的一点：DDL 触发器里不能访问 inserted 或 deleted 表，也拿不到被修改对象的旧定义 —— 所有元数据要靠 EVENTDATA() 解析 XML，而这个函数返回的内容取决于事件类型，CREATE_TABLE 和 ALTER_VIEW 的 XML 结构完全不同，没做适配就硬解析会出错。
