SQL Server中应查sys.triggers的is_disabled字段确认触发器状态，is_disabled=1表示禁用，0表示启用；需确保parent_id匹配目标表或视图的OBJECT_ID()，否则可能漏查。
SQL Server：查 sys.triggers 的 is_disabled 字段
别信 SSMS 图形界面右键菜单里“已禁用”的显示，也别只看执行语句有没有报错——SQL Server 不会主动告诉你触发器被关了。真正靠谱的方式是直接查系统视图：SELECT name, is_disabled FROM sys.triggers WHERE name = 'your_trigger_name'。如果返回的 is_disabled 是 1，说明它确实没在跑；0 才代表启用。注意：parent_id 要匹配目标表（或视图）的 OBJECT_ID()，否则可能漏查——比如触发器挂在视图上，却去查基础表的 OBJECT_ID，结果就是查不到。
MySQL：查 information_schema.TRIGGERS 的 STATUS
MySQL 同样静默失效，SHOW TRIGGERS 只显示当前库、不报状态，容易误判。必须用：SELECT TRIGGER_NAME, STATUS, EVENT_MANIPULATION, EVENT_OBJECT_TABLE FROM information_schema.TRIGGERS WHERE TRIGGER_NAME = 'your_trigger_name'。重点看三列：STATUS 必须是 ENABLED（不是 DISABLED 或空值）；EVENT_MANIPULATION 要和你要做的操作一致（比如你执行的是 UPDATE，这里就得是 UPDATE）；EVENT_OBJECT_TABLE 得对得上目标表名。跨库查询前记得先 USE db_name，否则查不到。
触发器“存在”不等于“生效”，权限和上下文也得核对
即使状态字段显示启用，也可能因其他原因卡住：
- MySQL 中触发器定义里的
DEFINER用户权限不足（比如DEFINER='app@localhost'但该用户没被授TRIGGER权限），会导致触发器跳过执行，且不报错 - SQL Server 中，若触发器建在某个 schema 下（如
Person.Address），而你用ALTER TABLE Address DISABLE TRIGGER uAddress漏掉 schema，命令会失败但提示模糊，实际状态没变 - MySQL 8.0+ 在
sql_log_bin = 0或binlog_format = STATEMENT时，部分触发器会被跳过——尤其当涉及复制或备份场景时容易忽略这点
UPDATE 无变更时触发器静默跳过，不是 bug 是设计
这个最容易被当成“触发器没启用”来排查，其实它根本没进触发逻辑：
- MySQL 8.0+ 默认行为：执行
UPDATE t SET x = x或UPDATE t SET name = 'old' WHERE id = 1（而当前name就是'old'），整条语句@@rowcount返回0，触发器完全不触发 - SQL Server 不会跳过，但如果你在触发器里依赖
inserted表做判断，而实际没行变更，inserted就为空，后续逻辑可能失效却不报错 - 验证方法很简单：执行完 UPDATE 后立刻查
SELECT @@rowcount，不是 0 才说明有真实变更、才可能走到触发器
真正麻烦的不是找不到开关，而是所有检查都“看起来正常”——状态对、权限够、语句改了数据，但触发器还是没动。这时候得盯住执行上下文：是不是在事务里被回滚了？有没有被另一个同名触发器覆盖？或者，最常被忽略的——你测试用的语句压根没命中触发器定义的事件类型或表。
