mysql查所有触发器应查询information_schema.triggers表,如select * from information_schema.triggers where trigger_schema = 'your_db_name';避免误用show triggers不选库或查不存在的mysql.triggers表。

MySQL 怎么查所有触发器
MySQL 里触发器信息全在 INFORMATION_SCHEMA.TRIGGERS 表里,直接查它最稳,不用猜表名或翻文档。
常见错误是去 SHOW TRIGGERS 却没指定数据库,结果报错 ERROR 1046 (3D000): No database selected;或者用 SELECT * FROM mysql.triggers——这表根本不存在,mysql 库里没有触发器元数据。
SELECT * FROM INFORMATION_SCHEMA.TRIGGERS WHERE TRIGGER_SCHEMA = 'your_db_name';- 想看当前库就先
USE your_db_name;,再加WHERE TRIGGER_SCHEMA = DATABASE(); - 字段重点看
EVENT_MANIPULATION(INSERT/UPDATE/DELETE)、EVENT_OBJECT_TABLE(作用在哪张表)、ACTION_TIMING(BEFORE/AFTER)
PostgreSQL 查触发器要连着函数一起看
PostgreSQL 的触发器本身不存逻辑,只存调用关系,真正代码在关联的函数里。只查 pg_trigger 会漏掉关键行为。
典型误操作是执行 \df 只看函数列表,却没和触发器绑定关系对上;或者用 SELECT tgname FROM pg_trigger; 但不知道怎么反查函数体。
- 查触发器定义:
SELECT tgname, tgtype, tgwhen, tgqual, tgfoid::regproc FROM pg_trigger t JOIN pg_class c ON t.tgrelid = c.oid WHERE c.relname = 'your_table'; - 函数体得额外查:
SELECT proname, pg_get_functiondef(oid) FROM pg_proc WHERE oid IN (SELECT tgfoid FROM pg_trigger); -
tgtype是位掩码,得用tgtype & 2 = 2判断是否为 INSERT 触发器,不能直接比数值
SQL Server 触发器元数据分散在多个系统视图
SQL Server 没有单表聚合所有触发器信息,sys.triggers 只存基础属性,定义文本得去 sys.sql_modules 关联查,漏掉 JOIN 就只能看到空壳。
容易踩的坑包括:用 OBJECT_DEFINITION(object_id) 查不到内容(因为加密了),或者用 sys.objects 替代 sys.triggers——后者才专管触发器,前者类型混杂。
- 查触发器+定义:
SELECT t.name, t.is_disabled, m.definition FROM sys.triggers t JOIN sys.sql_modules m ON t.object_id = m.object_id; - 限定某张表:
WHERE t.parent_id = OBJECT_ID('your_table') - 注意
is_disabled字段,很多线上问题其实是触发器被悄悄禁用了
跨数据库迁移时触发器常被漏掉
导出 SQL 时工具默认不包含触发器,比如 mysqldump --no-data 会跳过,pg_dump -s 默认也不导触发器函数体,除非加 --inserts 或显式 --trigger(但 PostgreSQL 实际没这个参数,得靠 --section=pre-data 配合)。
更隐蔽的问题是字符集:MySQL 触发器里如果用了 utf8mb4 相关 collation,迁到老版本 MySQL 可能报 Unknown character set: 'utf8mb4';PostgreSQL 函数里写死的模式名(如 public.your_table)在目标库若改了 schema 名,就会失效。
- MySQL 备份务必加
--triggers参数(默认是开启的,但脚本里常被删掉) - PostgreSQL 推荐用
pg_dump -Fc归档格式,还原时自动处理依赖顺序 - SQL Server 用
Generate Scripts向导时,必须手动勾选Triggers在 Table/View 选项页里
触发器不像普通表结构那么“静态”,它的执行时机、权限上下文、嵌套层级都可能让排查变得非线性——查到定义只是第一步,真出问题时往往得配合日志和 SHOW PROCESSLIST 或 pg_stat_activity 看实际调用链。










