如何查看数据库中所有已定义SQL触发器的详细方法

触发器这东西，平时写业务代码不一定天天碰，但真要排查问题或做数据库迁移时，绕不开它。今天就把几个主流数据库查触发器的套路拆开揉碎聊一聊——尤其是一些容易踩的坑和查完才发现“原来这里还有坑”的细节。

MySQL 必须先 USE 再 SHOW TRIGGERS，否则报 ERROR 1046

直接甩一句 SHOW TRIGGERS 就等着看 ERROR 1046 (3D000): No database selected 吧。这不是权限不够，是 MySQL 语法层面的硬性要求——它必须知道你想看哪个库的触发器。

• 正确姿势：先 USE your_db_name;，再跑 SHOW TRIGGERS。
• 想查别的库？不用切换当前库，直接 SHOW TRIGGERS FROM other_db; 就行。
• 模糊匹配用 SHOW TRIGGERS LIKE 'pay%'，但不支持正则或跨库组合。
• 注意：结果里 Statement 列默认只显示前 64 个字符，逻辑稍微长点就被截掉了——别靠它确认完整逻辑，容易翻车。

查完整定义必须用 INFORMATION_SCHEMA.TRIGGERS 或 SHOW CREATE TRIGGER

SHOW TRIGGERS 给出的信息其实不够用，它不返回可执行的 SQL 体。真正要看触发器到底干了什么，得从两个地方取：

• 批量查所有触发器的完整 ACTION_STATEMENT：查 information_schema.TRIGGERS 表，关键条件是 TRIGGER_SCHEMA = DATABASE()（动态取当前库）或者硬编码库名。
• 单个触发器精确还原：用 SHOW CREATE TRIGGER db_name.trigger_name，缺库名会报 ERROR 1360 (HY000): Trigger does not exist。
• ACTION_STATEMENT 字段里换行符存为 \n，复制出来要手动替换成真实换行才能执行。
• 触发器名区分大小写——Linux 下 myTrigger 和 mytrigger 是两个不相关的东西，踩过这个坑的人应该不少。

SQL Server 和 PostgreSQL 查触发器不能只看“触发器表”

MySQL 的 information_schema.TRIGGERS 是个聚合视图，但 SQL Server 和 PostgreSQL 的元数据是分散的，漏查关联对象就等于没看到逻辑：

• SQL Server：sys.triggers 只存开关状态和基础属性，真正的定义在 sys.sql_modules 里，必须 JOIN 才能拿到 m.definition；is_disabled = 1 意味着它存在但不生效——查半天发现没跑，先看看这个字段。
• PostgreSQL：pg_trigger 只存调用关系，函数体在 pg_proc，得用 pg_get_functiondef(oid) 提取；tgtype 是位掩码，判断 INSERT 要写 tgtype & 2 = 2，不能直接比数值。
• 跨库迁移时，很多工具默认不导出触发器——哪怕表结构和数据都同步了，行为也可能突变，别等到上线才发现少了关键逻辑。

触发器“没执行”不一定是代码错，先看权限和状态

静默失效比报错更难排查。常见卡点不在逻辑本身：

• 用户缺少 TRIGGER 权限，即使有 INSERT 权限，触发器也不会跑，而且不报任何错误提示——就像按了开关但没通电。
• SQL Server 里 is_disabled = 1、MySQL 里没显式禁用但定义里写了 DISABLE（极少见），都会让触发器形同虚设。
• 触发器里引用了已被删的字段，创建成功，首次触发时报 ERROR 1362 (HY000)，但日志里可能只记了事务回滚，不提触发器——排查方向很容易跑偏。
• MySQL 的 DEFINER 用户不存在或权限不足，会导致 ROUTINE_DEFINITION 在 information_schema.ROUTINES 里为空，同样适用于触发器关联的函数。

实际查的时候，别只盯着“怎么列出来”这一步。想清楚下一步：是要改逻辑？要迁移？还是排查不生效？每个目标对应的查法和验证点都不同，把工具用对路，比会一百条 SQL 都管用。