做MySQL开发和运维这些年我养成了一个习惯接到任何一张业务表第一件事不是看数据、看索引而是先查这张表上到底挂了哪些触发器。为什么因为触发器这东西不在你的业务代码里却在数据落库的瞬间悄悄执行。表结构一变、批量更新一跑那些隐形的触发器可能就把数据改了甚至把性能拖垮。今天这篇我就围绕“查看触发器TRIGGERS”这个核心需求把MySQL里查触发器、理解触发器、用对触发器这一整条链路讲透。无论你是刚入行的初级开发还是被历史触发器折磨过的老运维这篇文章应该都能给你点实在的东西。1. 触发器到底是什么——先弄清楚几个基本问题1.1 触发器的本质与工作原理触发器TRIGGER是MySQL中一种特殊的存储程序它不像存储过程那样需要显式调用而是注册在某个具体数据表上监听特定的事件。当这个事件发生时MySQL会自动执行触发器里定义的那段SQL逻辑。用大白话说触发器就是数据库层面的“传感器”。你在表上装了它只要表里的数据发生指定类型的变动它就会被激活。这个“变动”在MySQL里分三类INSERT插入、UPDATE更新、DELETE删除。触发器还可以细分执行时机BEFORE在变动发生之前执行和 AFTER在变动完成之后执行。所以排列组合下来一张表最多可以挂6个基本触发器BEFORE INSERT、AFTER INSERT、BEFORE UPDATE、AFTER UPDATE、BEFORE DELETE、AFTER DELETE。我见过不少刚接触数据库的朋友把触发器和存储过程、函数搞混。这里做一个简单区分存储过程PROCEDURE是你主动调用才执行函数FUNCTION是在SQL表达式里调用并返回一个值而触发器是表上挂了钩子事件一到自动触发不需要也不允许你显式调用。它和事件调度器EVENT也不是一回事事件调度器是按时间计划周期执行触发器是跟着数据变动即时执行。理解这个区别后面排查问题的时候思路会清晰很多。1.2 触发器的生命周期与核心使用场景一个触发器从创建到失效大致经历这几个阶段创建CREATE TRIGGER、使用自动触发执行、查看SHOW TRIGGERS / 查询元数据表、修改DROP后重建MySQL没有ALTER TRIGGER、删除DROP TRIGGER。MySQL从5.0.2版本开始支持触发器。8.0之后对触发器的元数据管理和字符集处理做了不少改进但对老旧的5.7版本库你平时操作触发器遇到的那些诡异现象往往就是版本行为差异导致的这点后面会详细展开。在实际项目里触发器最典型的使用场景有几类审计日志核心业务表每次增删改自动把旧值、新值、操作时间写进日志表。数据完整性兜底比如更新订单表时自动维护订单明细表的汇总字段。异构同步辅助表数据变动时写一张待同步的中间表由下游任务去消费。防止误操作用BEFORE DELETE触发器拦截特定条件下的删除操作直接SIGNAL抛错。正因为触发器的执行对业务代码是透明的项目里埋下的“隐性逻辑”比代码里写得明明白白的调用后患更大。查清楚线上每张表挂了什么触发器其实是在还原系统里一张被遗忘的逻辑地图。1.3 为什么要特别关注“查看触发器”这个操作很多同学平时不太看触发器直到出了线上事故才想起来查。我遇到过几次印象深刻的场景某一次是业务反馈某张订单表更新一条记录后莫名其妙多了好几条日志数据量翻了好几倍。排查到最后发现表上挂了一个AFTER UPDATE触发器而这个触发器本身又UPDATE了另一张关联表关联表上恰好也有触发器层层嵌套全部执行了一遍。另一次是接手老项目做数据库迁移迁移工具默认只导表结构和数据触发器全部落在老库里。结果新环境跑业务该写的审计日志一条都没有。后来统一用查询语句把触发器DDL捞出来在目标库挨个重建才恢复。所以“查看触发器”绝不只是翻一眼元数据那么简单。它是排查隐性逻辑、做数据库迁移、梳理系统依赖、评估性能隐患时必不可少的第一步。接下来我给出几种最常用的查看方式按场景选就行。2. 查看触发器的几种姿势——从命令行到可视化工具2.1 SHOW TRIGGERS最快捷的查询方式如果你只是想快速看一眼当前库有哪些触发器SHOW TRIGGERS命令是最直接的。SHOW TRIGGERS;这条命令会返回当前数据库默认库下所有触发器的基本信息。如果当前连接的默认库不对可以加FROM指定库名SHOW TRIGGERS FROM your_db;返回的列里面比较关键的有Trigger触发器名称。Event触发事件INSERT、UPDATE或DELETE。Table触发器所在表。Statement触发器执行体也就是每次触发会跑的SQL。TimingBEFORE还是AFTER。Created触发器创建时间。sql_mode创建触发器时的SQL模式。Definer定义者也就是以哪个用户身份执行触发器。SHOW TRIGGERS的优点是简单直观不需要记元数据表结构。但它有两个明显的短板一是不支持WHERE过滤条件如果你想查“某个特定表上的所有触发器”或者“名字带某关键字的触发器”只能全量捞出来自己在结果集里筛二是返回的信息量并不完整比如触发器的字符集设置、创建时的上下文信息看不到。所以SHOW TRIGGERS适合开发环境里快速确认“这张表有没有触发器”不适合做精细化的批量管理系统。2.2 information_schema.TRIGGERS最灵活的元数据查询要说查看触发器最专业的方式还得是查系统元数据库 information_schema 里的 TRIGGERS 表。这张表记录了整个MySQL实例里所有数据库的所有触发器信息比SHOW TRIGGERS全得多。常用查询语句-- 查看某个库下的所有触发器 SELECT * FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA your_db\G -- 查看某张表上的所有触发器 SELECT TRIGGER_NAME, EVENT_MANIPULATION, ACTION_TIMING, ACTION_STATEMENT FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA your_db AND EVENT_OBJECT_TABLE orders\GTRIGGERS表的核心字段强烈建议记住这几个字段名含义TRIGGER_CATALOG触发器所属目录MySQL里通常是defTRIGGER_SCHEMA触发器所在数据库名TRIGGER_NAME触发器名称EVENT_MANIPULATION触发事件INSERT/UPDATE/DELETEEVENT_OBJECT_SCHEMA触发器所绑定的表的库名EVENT_OBJECT_TABLE触发器所绑定的表名ACTION_ORDER同表同事件多个触发器的执行顺序8.0新增ACTION_CONDITION触发条件一般NULLACTION_STATEMENT触发器执行体也就是那串SQL逻辑ACTION_ORIENTATION触发方式一般ROW行级ACTION_TIMING执行时机BEFORE/AFTERACTION_REFERENCE_OLD_TABLE旧表引用名一般NULLACTION_REFERENCE_NEW_TABLE新表引用名一般NULLSQL_MODE创建时的SQL模式DEFINER定义者账号CHARACTER_SET_CLIENT建触发器时客户端字符集COLLATION_CONNECTION建触发器时连接排序规则DATABASE_COLLATION所在库的默认排序规则CREATED创建时间这个表是标准的数据库字典表你可以用任意SQL做过滤、排序、统计。我在实际工作中使用频率最高的三条SQL是-- 统计每个库的触发器数量快速盘点 SELECT TRIGGER_SCHEMA, COUNT(*) AS cnt FROM information_schema.TRIGGERS GROUP BY TRIGGER_SCHEMA; -- 找出所有绑定在orders表上的触发器 SELECT TRIGGER_NAME, EVENT_MANIPULATION, ACTION_TIMING FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_TABLE orders; -- 查看触发器执行体内容定位具体逻辑 SELECT ACTION_STATEMENT FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA your_db AND TRIGGER_NAME trg_orders_after_insert;这里有一个小技巧如果你是在迁移触发器或者要把某个触发器原样复制到另一台库可以用SHOW CREATE TRIGGER拿到完整的DDL。例如SHOW CREATE TRIGGER your_db.trg_orders_after_insert\G执行结果里有SQL Original Statement一栏里面就是可以直接拿过去用的完整建触发器语句。用这种方式迁移触发器比自己手写CREATE TRIGGER靠谱得多至少不会漏掉Definer、sql_mode这些容易踩坑的属性。2.3 用图形化工具查看触发器命令行虽好但很多人日常用的是Navicat或MySQL Workbench这类图形化工具。用它们查看触发器也很方便。在Navicat里展开左侧的数据库连接找到目标数据库节点下的“触发器”目录点击就能看到该库下所有触发器列表。双击任意一条会打开一个窗口上面是触发器属性下面通常能看到触发器的源SQL。如果想看某张特定表的触发器展开该表节点里面也有触发器子节点一目了然。MySQL Workbench的做法类似在Navigator面板里展开数据库能看到Triggers节点右键可以刷新、查看触发器的DDL也可以直接新建触发器。页面里会有模板化的CREATE TRIGGER生成器选择库、表、时机、事件填入执行体即可。不过图形化工具有一个需要注意的地方默认展示的触发器列表可能只包含当前选定库的触发器而且大库的触发器多时列表刷新会比较慢。另外如果你连的是生产库建议只在只读事务里查看别顺手在图形界面里改触发器。所有变更类操作都走脚本评审这是我在团队里反复强调的规矩。2.4 查看触发器定义与其他对象的关联触发器里常常会引用存储过程、函数或者别的表。排查问题的时候只看触发器本身不够还得顺藤摸瓜找到它调用链路上的其他对象。MySQL里面没有直接的“对象依赖关系图”可以用一条SQL查出来但可以结合information_schema里的ROUTINES表和TRIGGERS表做关键词匹配。比如查所有触发器里出现了“sp_”或“func_”开头的存储过程名SELECT DISTINCT t.TRIGGER_NAME, t.ACTION_STATEMENT FROM information_schema.TRIGGERS t WHERE t.ACTION_STATEMENT LIKE %sp_% OR t.ACTION_STATEMENT LIKE %func_%;这种查询精度有限但能帮你快速定位到可疑的触发器再去读执行体里具体调了什么。另一个维度的查看是看触发器和表的关系把EVENT_OBJECT_TABLE和触发器执行体里出现的表名对照一下能发现不少“改了A表数据却悄悄动了B表”的隐蔽逻辑。这个在数据流梳理阶段非常有用。3. 触发器实操从创建到验证把每一步走扎实3.1 创建触发器的完整语法与参数选择虽然标题是“查看触发器”但查看的前提是理解触发器长什么样。创建触发器的基本语法是CREATE [DEFINER user] TRIGGER [IF NOT EXISTS] trigger_name trigger_time trigger_event ON tbl_name FOR EACH ROW [FOLLOWS | PRECEDES other_trigger_name] trigger_body各段含义拆开说DEFINER定义者默认是当前用户。触发器执行时MySQL会以定义者的权限来执行意味着定义者必须有足够的权限去操作触发器执行体里涉及的表。trigger_name触发器名字数据库内唯一建议命名时体现“表名时机事件”比如trg_orders_after_insert以后排查的时候一眼能看懂。trigger_timeBEFORE或AFTER。trigger_eventINSERT、UPDATE、DELETE。ON tbl_name绑定在哪张表。FOR EACH ROW声明这是行级触发器也就是说影响的每一行数据都会触发一次。FOLLOWS / PRECEDES8.0以后可以用它指定同一张表上多个同事件触发器的执行先后顺序旧版本没有这个能力同一事件上出现多个触发器的顺序是不可控的。trigger_body触发器执行体可以是一段复合语句用BEGIN...END包裹里面可以写SQL、变量、流程控制等。用一个简单例子说明DELIMITER $$ CREATE TRIGGER trg_orders_after_insert AFTER INSERT ON orders FOR EACH ROW BEGIN INSERT INTO orders_audit(order_id, action, action_time) VALUES (NEW.id, INSERT, NOW()); END$$ DELIMITER ;这段代码的意思很直白orders表每插入一条新记录就往orders_audit表里写一条审计日志记录新插入行的ID、动作类型和操作时间。注意INSERT触发器的执行体里可以用NEW关键字访问新插入行的字段值UPDATE触发器同时有NEW和OLDDELETE触发器用OLD。这是写触发器必须掌握的基本概念。实操中最大的坑之一是很多新手用惯了客户端工具忘了DELIMITER的存在。MySQL客户端默认以分号作为语句结束符而触发器执行体里通常有分号如果不先临时把结束符改掉CREATE TRIGGER语句会被客户端错误地截断。上面例子里DELIMITER $$和DELIMITER ;的配合就是为了解决这个问题。3.2 实战案例订单表自动审计触发器空讲概念不落地很多细节容易漏。我这里给一个完整的实战案例大家可以直接抄去改。需求场景订单表orders发生增删改时自动把变更记录写到order_history表记录操作前值、操作后值、操作时间和操作类型。假设orders表结构简化为CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32), status TINYINT, amount DECIMAL(10,2), updated_at DATETIME );审计表结构CREATE TABLE order_history ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT, old_status TINYINT, new_status TINYINT, action VARCHAR(10), changed_at DATETIME );然后创建三个触发器。第一个插入审计DELIMITER $$ CREATE TRIGGER trg_orders_after_insert AFTER INSERT ON orders FOR EACH ROW BEGIN INSERT INTO order_history(order_id, old_status, new_status, action, changed_at) VALUES (NEW.id, NULL, NEW.status, INSERT, NOW()); END$$ DELIMITER ;第二个更新审计DELIMITER $$ CREATE TRIGGER trg_orders_after_update AFTER UPDATE ON orders FOR EACH ROW BEGIN INSERT INTO order_history(order_id, old_status, new_status, action, changed_at) VALUES (NEW.id, OLD.status, NEW.status, UPDATE, NOW()); END$$ DELIMITER ;第三个删除审计DELIMITER $$ CREATE TRIGGER trg_orders_after_delete AFTER DELETE ON orders FOR EACH ROW BEGIN INSERT INTO order_history(order_id, old_status, new_status, action, changed_at) VALUES (OLD.id, OLD.status, NULL, DELETE, NOW()); END$$ DELIMITER ;创建完成后就可以用前面第二章讲的方法去验证SELECT TRIGGER_NAME, EVENT_MANIPULATION, ACTION_TIMING FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_TABLE orders;正常会返回三条记录。接着做一次实际DML去audit表查一下确认触发器真的把日志写进去了。很多线上的触发器故障往往是在这一步行验证的时候才暴露出来的所以别省这一步。3.3 触发器与存储过程的配合使用触发器执行体里如果逻辑比较复杂最好别把一长串SQL直接全写在触发器里。我更推荐的做法是把复杂逻辑封装成存储过程触发器只负责调用它。这样两个好处一是触发器本身短小清晰查看时一眼能懂二是同样的逻辑如果其他地方也要用可以复用。例子DELIMITER $$ CREATE PROCEDURE sp_sync_order_stats(IN p_order_id INT) BEGIN UPDATE order_summary SET total_orders total_orders 1, total_amount total_amount IFNULL( (SELECT amount FROM orders WHERE id p_order_id), 0) WHERE stat_date CURDATE(); END$$ CREATE TRIGGER trg_orders_after_insert_call_sp AFTER INSERT ON orders FOR EACH ROW BEGIN CALL sp_sync_order_stats(NEW.id); END$$ DELIMITER ;这里有一个必须强调的环节存储过程或者触发器里如果发生异常尤其是有SIGNAL抛错时整条DML操作会一起回滚。比如BEFORE INSERT触发器里写了一个不满足条件就SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT blocked by trigger的逻辑当触发条件满足时插入操作会直接报错失败。对外表现为“业务代码没报错但数据就是写不进去”。排查这类问题第一反应就应该是去查表上的触发器。另外要提醒一点在触发器里查询同一张表要格外小心。比如在AFTER UPDATE触发器里对同一张表再做UPDATE很可能导致触发器被再次触发。如果链路设计得不谨慎轻则数据反复修改重则触发迭代嵌套直到超过限制报错。我自己习惯的做法是在触发器里不修改触发它的那张表本身审计信息写到单独的表汇总用的事务尽量前置到业务代码里把触发器做成只读来源和写旁路数据的角色。3.4 用查看命令验证触发器的实际运行状态触发器没有“启用/禁用”状态的专门开关它最接近“禁用”的操作是DROP TRIGGER最接近“轻量停用”的手段是修改触发器执行体让它只做无害的no-op操作。所以验证一个触发器是否在生效就只能靠实际DML后观察副作用。最标准的验证流程是这样的第一步用information_schema.TRIGGERS确认目标触发器存在拿到触发时机、事件、绑定表。第二步提前看一眼审计表或者相关目标表的当前数据量作为基线。第三步执行一条干净的DML比如INSERT一条测试数据紧接着检查目标表的数据变化。第四步用SELECT * FROM information_schema.TRIGGERS WHERE ...\G再核对一次确认执行体没写错。注意如果在事务里执行DML然后回滚触发器的副作用也会跟着回滚。有个同事曾经因为在一个事务里验证AFTER INSERT日志触发器最后ROLLBACK了结果触发器执行没报错但日志也消失了他硬是排查了一下午。所以验证时要么直接COMMIT要么把查询也放在同一事务里获取一致视图。4. 常见问题与排查技巧实录4.1 触发器不触发的几种晴天霹雳场景场景一事件类型搞混。最常见的是用UPDATE语句时期望触发器被触发结果建的是INSERT触发器。或者用REPLACE INTO的时候实际包含DELETE和INSERT两个阶段但只建了UPDATE触发器导致数据被删除重建触发器却没有按预期触发。这里的关键认知是REPLACE INTO会先尝试DELETE旧行再INSERT新行INSERT ... ON DUPLICATE KEY UPDATE在发生冲突时走的是UPDATE路径。设计触发器和排查时候先想清楚语句的实际事件流。场景二Definer权限不足。触发器执行时以DEFINER的权限运行。如果触发器定义者是某个已经被删除的账号或者该账号对执行体里的表没有权限即使创建成功运行时也会报错或者静默跳过。MySQL里触发器执行错误会导致整个语句失败容易被误认为是业务逻辑问题。遇到这种情况优先查DEFINER字段以及对应账号的存在性和权限。场景三执行体里用了不允许的语句。比如在触发器里直接操作触发器自己绑定的那张表的相同事件或者某些情况下触发了临时表的限制。MySQL对触发器的执行体有明确约束不能修改触发器所绑定的表本身BEFORE/AFTER都不行8.0的特定版本对部分情况有放宽但最稳妥的做法是别这么写、不能返回结果集、存储函数里不能修改表等。如果创建时合法运行时报错把错误日志翻出来看很多时候错误信息直接指向了触发器名字。4.2 版本差异与SQL模式的坑MySQL 5.7到8.0之间触发器行为有一些细微变化。比如8.0开始同一个表上同一事件允许存在多个触发器并且可以通过FOLLOWS/PRECEDES控制顺序而5.7及更早版本里同一张表的同一事件只能有一个触发器。这意味着老库往8.0迁移时如果老库已经变相突破了限制新库的行为可能完全不同。SQL_MODE是另一个容易忽略的坑。创建触发器的时候SQL_MODE会被记录在TRIGGERS表里。执行触发器时MySQL会切到被记录的SQL_MODE。如果创建时是宽松模式比如没有ONLY_FULL_GROUP_BY到了执行阶段因为字段分组或类型转换行为不同可能算出完全不一样的结果。碰到线上与开发环境触发器行为不一致先把两边TRIGGERS表里的SQL_MODE、CHARACTER_SET_CLIENT、COLLATION_CONNECTION三列拉出来对比。我处理过一个具体案例一个触发器里做了DECIMAL和字符串的隐式转换开发环境MySQL 8.0的默认SQL_MODE下跑得正常生产环境是历史遗留配置创建时的SQL_MODE和现在不同导致精度丢失金额对不上账。最后统一重建了触发器才解决。所以查看触发器时养成同时查看SQL_MODE字段的习惯很有必要。4.3 触发器的性能与递归问题触发器最大的性能风险是行级触发器的放大效应。FOR EACH ROW语义下一条UPDATE扫描了十万行触发器就会执行十万次。哪怕每次只做一次简单INSERT累积起来IO和日志写入量都很可观。查看触发器时要特别留意ACTION_STATEMENT里是否有嵌套查询、是否有子查询扫大表、是否调用了存储过程。递归调用的问题也一样。A表触发器改了B表B表触发器改了C表C表触发器又改回A表检查不出来线上就会死循环。MySQL对递归调用的保护有max_sp_recursion_depth参数但那是针对存储过程自身的递归触发器链路之间的相互调用并不会完全被这个参数限制住。实际操作里我处理过一条UPDATE语句被触发器无限放大到超时的案例最后把三张表的触发器链条全部梳理出来靠重建其中一个触发器、去掉多余的联动才解决。给一个现场排查用得到的技巧当UPDATE特别慢时用mysql的general_log或者性能模式performance_schema确认有没有额外的SQL在往外发。如果观察到除了应用发出的SQL之外还有一串系统自动执行的INSERT/UPDATE那基本就是触发器在干活。用SHOW PROCESSLIST观察会话执行的语句也能看到触发器导致的后续语句。4.4 触发器查询速查表为了日常查起来顺手我把常用命令整理成了速查表贴在下面操作需求命令/查询查看当前库所有触发器SHOW TRIGGERS;查看指定库所有触发器SHOW TRIGGERS FROM your_db;查看指定表的所有触发器SELECT * FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_SCHEMAyour_db AND EVENT_OBJECT_TABLEorders\G查看触发器完整DDLSHOW CREATE TRIGGER your_db.trg_orders_after_insert;统计每个库触发器数量SELECT TRIGGER_SCHEMA, COUNT(*) FROM information_schema.TRIGGERS GROUP BY TRIGGER_SCHEMA;查看触发器执行体SQL内容SELECT ACTION_STATEMENT FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMAyour_db AND TRIGGER_NAMEtrg_orders_after_insert;查看触发器定义者SELECT DEFINER FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMAyour_db AND TRIGGER_NAMEtrg_orders_after_insert;这个表我建议存到自己的笔记里尤其是SHOW CREATE TRIGGER和information_schema查询这两条基本覆盖了绝大多数日常查看场景。最后说几句经验触发器这个东西单拿出来看功能很强大一旦放到复杂的业务系统里就是一把双刃剑。我自己在实际操作中体会最深的一点是查看触发器应当成为一种例行工作。每次新接手一个数据库用一条SELECT把整个实例的触发器清点一遍花不了几分钟但能避免非常多“神秘数据变化”的半夜抓狂时刻。另外无论谁在库上新增或者删除触发器一定要留好DDL脚本和变更记录。触发器不像是普通数据表业务代码里根本看不到它在跑如果没有文档和脚本后来的维护者只能靠一条条查元数据来猜当初的意图代价非常大。真希望MySQL以后能出个更友好的对象依赖图谱在那之前勤查information_schema.TRIGGERS总不会有错。