1. 触发器到底是什么别被教科书绕晕了它就是数据库里的“自动闹钟”很多人第一次听到“触发器trigger”这个词脑子里立刻浮现出一堆抽象定义“一种特殊的存储过程”“在特定事件发生时自动执行”“不通过调用而被激活”……听着像在背《数据库原理》期末考点。但说实话我在某实验室带学生做数据管理项目时第一堂实操课就直接扔给他们一个真实场景一张订单表每次插入新订单必须同步更新商品库存表的剩余数量如果库存不足还得立刻拦住这笔插入操作——这时候没人再纠结“什么是触发器”所有人盯着屏幕等我敲出第一行CREATE TRIGGER。触发器本质上就是一个数据库级别的自动化响应机制。它不依赖应用层代码也不需要程序员手动写if-else判断而是把业务规则“焊死”在数据表结构里。你把它理解成数据库自带的“条件反射”更贴切当某张表被 INSERT、UPDATE 或 DELETE 时数据库内核会像按下开关一样瞬间拉起一段预设好的 SQL 逻辑。这个动作对上层应用完全透明哪怕你用的是 Python Flask、Java Spring Boot甚至 Excel 连接 ODBC 直接改数据只要操作触达数据库触发器就一定会响。为什么非得用它举个最典型的例子某高校教务系统里学生选课表和课程容量表是两张独立表。如果靠应用层控制选课人数上限一旦并发量上来比如抢热门公选课那几分钟两个请求几乎同时读取到“还有1个名额”然后都判断“可以插入”结果就超员了。而触发器是在数据库事务最底层执行的它能确保“读取当前余量→判断是否允许→更新余量”这三步原子化完成中间插不进任何其他操作。这不是锦上添花的功能而是数据一致性的最后一道保险丝。关键词“触发器trigger”之所以持续出现在 DBA 和后端开发者的高频搜索列表里根本原因在于它解决的是跨操作、强一致性、低延迟响应这三重硬需求。它不替代业务逻辑但能兜住那些“万一漏掉就出大事”的关键校验点。适合谁学不是只给资深 DBA 看的而是所有要和关系型数据库打交道的人——从刚写 CRUD 的实习生到设计高并发系统的架构师只要你的数据不能错、不能乱、不能晚你就绕不开触发器。2. 触发器的设计逻辑与方案选型为什么不是所有场景都该用它2.1 三种触发时机的本质区别INSERT/UPDATE/DELETE 不是并列关系而是分层防御很多初学者以为触发器就是“表一动我就动”于是不管三七二十一给每张核心表都配上 INSERT、UPDATE、DELETE 三套触发器。我带过的某位 A 同学就吃过这个亏他在用户行为日志表上建了 UPDATE 触发器目的是记录每次修改的旧值和新值。结果上线后发现日志表体积暴涨三倍查询慢得像卡顿的视频。排查才发现他写的 UPDATE 触发器里没加WHERE条件过滤连UPDATE user_log SET access_time NOW()这种单纯刷新时间戳的操作也触发了完整日志记录逻辑。这里的关键认知偏差在于三种触发时机对应的是完全不同的数据语义层级不是功能选项而是责任划分。INSERT 触发器本质是“准入审查员”。它在数据落库前执行最适合做强制约束如检查邮箱格式、拦截非法状态值、默认填充如自动生成 UUID、设置创建时间、前置关联校验如检查外键引用是否存在。它的最大优势是“防患于未然”但缺点是无法访问“旧数据”因为数据还没进来。UPDATE 触发器本质是“变更审计员状态协调员”。它能同时拿到OLD和NEW伪记录所以天然适合做差异比对如只在价格字段变化时才更新价格历史表、级联更新如修改部门名称时自动更新所有下属员工记录中的部门字段、状态机流转校验如工单状态只能从“待处理”→“处理中”→“已完成”禁止跳转。注意UPDATE 触发器的执行开销明显高于 INSERT因为它要加载两份数据镜像。DELETE 触发器本质是“善后清道夫”。它只持有OLD记录最适合做软删除标记把is_deleted1替代物理删除、归档迁移把删掉的数据自动插入历史归档表、反向清理如删除用户时同步清除其关联的收藏、评论、会话记录。特别提醒DELETE 触发器里绝对不要写DELETE FROM xxx WHERE id OLD.id这类语句否则极易引发递归触发导致数据库直接报错退出。提示触发器不是万能胶水。我见过最危险的误用是有人用 DELETE 触发器去“恢复误删数据”——试图在触发器里把OLD数据重新 INSERT 回原表。这不仅违反事务隔离原则更会在高并发下制造死锁。真要防误删应该用备份策略或开启 binlog而不是寄希望于触发器“时光倒流”。2.2 BEFORE vs AFTER执行时机选错整个逻辑就崩了光选对触发事件还不够BEFORE 和 AFTER 的选择才是决定成败的临门一脚。这就像做饭时盐是出锅前放还是炖煮时放——差一秒味道天壤之别。BEFORE 触发器在数据库执行实际 INSERT/UPDATE/DELETE 操作之前运行。它的核心价值在于干预操作本身。你可以修改NEW行的字段值如SET NEW.updated_at NOW()用SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 库存不足主动抛出错误让整个事务回滚基于OLD或NEW值做复杂计算并将结果赋给其他字段。注意BEFORE UPDATE 中修改NEW.column是安全的但修改OLD.column会报错BEFORE INSERT 中只能改NEW因为OLD根本不存在。AFTER 触发器在数据库完成 INSERT/UPDATE/DELETE 操作之后运行。此时数据已真实落库事务尚未提交仍可回滚。它的核心价值在于基于已确认结果的后续动作。你可以查询刚插入的记录 IDLAST_INSERT_ID()在 AFTER 中才稳定可用更新其他关联表如订单插入后更新客户总消费额调用存储过程发送通知如新订单生成后调用短信接口。关键限制AFTER 触发器里绝对不能修改触发它的那张表MySQL 会直接报错Cant update table xxx in stored function/trigger because it is already used by statement which invoked this stored function/trigger.。这是硬性死锁防护机制不是 bug。我做过一个电商库存同步项目最初用 AFTER INSERT 写订单触发器去扣减库存结果遇到极端情况两个并发请求同时插入同一商品订单AFTER 触发器读到的库存都是“1”都执行扣减最终库存变成 -1。后来改成 BEFORE INSERT在真正插入前就查库存、判断、抛错问题彻底消失。这个教训让我牢牢记住涉及“检查-执行”原子性要求的场景必须用 BEFORE涉及“执行后联动”的场景才用 AFTER。2.3 方案取舍触发器 vs 应用层逻辑 vs 外键约束——什么时候该放手触发器不是银弹。面对一个数据一致性需求工程师必须在三个工具箱里做选择外键约束Foreign Key、应用层业务逻辑、触发器Trigger。我的经验是画一张决策树能否用外键解决如果只是简单的“子表记录必须有父表对应项”比如订单明细里的order_id必须存在于订单主表中那外键是首选。它由数据库引擎原生支持性能最优且自动维护参照完整性。但外键无法处理复杂逻辑如“只有状态为‘已支付’的订单才能添加明细”也无法跨库、跨表做条件判断。能否在应用层搞定如果逻辑简单、并发压力小、且团队有统一的 ORM 或 DAO 层应用层校验更灵活、易调试、易测试。比如用户注册时检查用户名是否重复完全可以在 Service 层先SELECT COUNT(*)再决定是否INSERT。但风险在于一旦有其他途径绕过应用如 DBA 直连 SQL、第三方 ETL 工具、遗留系统直连约束就失效了。必须用触发器吗当且仅当满足以下全部条件时我才拍板上触发器逻辑必须100% 由数据库保证不允许任何绕过涉及多表协同更新或校验且这些表可能被不同应用、不同模块访问需要在单条 SQL 语句级别实现原子性如上面库存超卖案例逻辑相对稳定不会频繁变更触发器修改需 DBA 审批上线成本高。举个反例某公司曾用触发器实现“用户等级自动升级”。每当用户积分增加触发器检查积分段自动更新等级字段。结果运营部门三天两头调整升级规则每次都要停服改触发器DBA 苦不堪言。后来拆成应用层定时任务数据库事件反而更可控。3. 核心细节解析与实操要点从语法到避坑的全链路拆解3.1 语法骨架与关键参数每一行代码背后都有明确意图MySQL 中创建触发器的标准语法如下以 BEFORE INSERT 为例DELIMITER $$ CREATE TRIGGER trigger_name BEFORE INSERT ON table_name FOR EACH ROW BEGIN -- 触发器主体逻辑 IF NEW.email NOT REGEXP ^[A-Za-z0-9._%-][A-Za-z0-9.-]\.[A-Za-z]{2,}$ THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 邮箱格式不正确; END IF; SET NEW.created_at NOW(); SET NEW.status active; END$$ DELIMITER ;这段代码里每个关键字都不是摆设而是承载着明确的工程意图DELIMITER $$切换语句结束符。这是最容易被忽略却最致命的一步。因为触发器体内的;是 SQL 语句分隔符而外部CREATE TRIGGER语句本身也需要以;结束。不改分隔符MySQL 会把BEGIN...END;里的第一个;就当成CREATE语句的结束导致语法错误。$$只是示例你可以用//、等任意非分号字符但必须前后一致。BEFORE INSERT ON table_name精准锚定触发边界。这里table_name必须是当前数据库下的真实表名不支持视图、临时表或跨库表如other_db.table。如果你需要跨库操作必须在触发器体内用db_name.table_name显式指定。FOR EACH ROW声明作用粒度。这是 MySQL 触发器的强制要求意味着每影响一行数据就执行一次触发器逻辑。没有FOR EACH STATEMENT这种选项PostgreSQL 支持但 MySQL 不行。这意味着INSERT INTO t VALUES (1),(2),(3);会触发三次而不是一次。NEW和OLD数据镜像的唯一入口。NEW代表即将插入或更新后的行INSERT/UPDATE 有效OLD代表被更新或删除前的行UPDATE/DELETE 有效。它们是只读的伪记录你不能SET NEW NULL但可以SET NEW.column value。特别注意NEW在 BEFORE 中可修改在 AFTER 中只读OLD在 BEFORE 和 AFTER 中都只读。SIGNAL SQLSTATE主动终止事务的唯一合法方式。这是比RETURN更强硬的手段。SQLSTATE 45000是通用错误码MESSAGE_TEXT会作为异常信息返回给客户端。应用层捕获到这个错误就知道是触发器拦截了而不是数据库连接失败。实操心得我习惯在所有触发器开头加一行注释-- [业务场景]防止XX确保YY。比如-- [订单风控]防止负库存下单。这样半年后别人接手一眼就能看懂这段“黑盒逻辑”存在的意义而不是对着IF NEW.qty 0 THEN ...发呆。3.2 字段级操作的隐藏陷阱NULL、AUTO_INCREMENT 与 TIMESTAMP 的特殊处理触发器里看似简单的字段赋值藏着不少“温柔的坑”。我整理了最常踩的三类NULL 值的暧昧性如果表定义中某字段允许 NULLcolumn VARCHAR(50) NULL你在 BEFORE INSERT 中SET NEW.column NULL没问题但如果该字段有NOT NULL约束SET NEW.column NULL会直接报错Column column cannot be null。更隐蔽的是SET NEW.column 空字符串和SET NEW.column NULL在业务语义上天差地别但新手常混淆。我的做法是在触发器里显式判断IF NEW.column IS NULL THEN SET NEW.column default_value; END IF;把模糊性消灭在源头。AUTO_INCREMENT 字段的“不可见性”对于主键id INT AUTO_INCREMENTNEW.id在 BEFORE INSERT 中永远是NULL即使你手动SET NEW.id 100MySQL 也会忽略按自增规则分配。但在 AFTER INSERT 中NEW.id就是真实的、已分配的 ID 值。这个特性被广泛用于“获取刚插入记录 ID 并写入关联表”。但要注意LAST_INSERT_ID()函数在 AFTER 中才返回准确值BEFORE 中调用是无效的。TIMESTAMP/DATETIME 的时区陷阱如果字段定义为created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMPMySQL 会在插入时自动填充。但如果你在 BEFORE INSERT 中SET NEW.created_at NOW()就会覆盖默认值。问题来了NOW()返回的是服务器系统时区的时间而CURRENT_TIMESTAMP默认是数据库时区可通过SELECT time_zone查看。如果两者不一致比如服务器用 UTC数据库设为 08:00你手动设置的时间就比默认值慢 8 小时解决方案统一用CURRENT_TIMESTAMP或NOW()并在数据库初始化时SET time_zone 08:00避免混用。3.3 性能敏感点与资源消耗别让触发器成为数据库的“慢性毒药”触发器最大的隐性成本不是写法而是它悄无声息吃掉的数据库资源。我监控过某金融系统一个看似简单的AFTER UPDATE ON account_balance触发器导致高峰期 CPU 使用率飙升 40%。根因不是逻辑复杂而是它里面嵌套了三次SELECT ... FROM transaction_history WHERE account_id NEW.id ORDER BY create_time DESC LIMIT 1查询。触发器性能有三大雷区禁止在触发器内执行耗时查询触发器运行在事务上下文中所有 SQL 都会占用连接、锁、内存。SELECT语句如果没走索引或者扫描大量数据会直接拖慢主 SQL 的执行。我的铁律是触发器内只允许主键查询SELECT * FROM t WHERE id NEW.ref_id或极窄范围查询SELECT * FROM t WHERE status pending AND created_at DATE_SUB(NOW(), INTERVAL 1 HOUR)。任何需要LIKE %xxx%、ORDER BY ... LIMIT NN100、JOIN 多张大表的操作一律移出触发器改用异步消息队列处理。警惕隐式类型转换导致的索引失效比如触发器里写IF NEW.phone 13812345678 THEN ...而phone字段是VARCHAR(20)。MySQL 会把数字13812345678转成字符串再比较但这个过程可能导致phone字段上的索引无法使用。正确写法是IF NEW.phone 13812345678 THEN ...保持类型严格一致。递归触发的雪崩效应最经典的例子表 A 的 UPDATE 触发器去 UPDATE 表 B而表 B 的 UPDATE 触发器又去 UPDATE 表 A。MySQL 默认禁止这种直接递归会报错但间接递归很危险。比如A 的触发器调用存储过程 PP 里又 UPDATE 了 A。这种链式调用很难排查。我的防御策略是在触发器开头加IF in_trigger_loop IS NOT NULL THEN LEAVE proc_label; END IF;并在触发器结尾SET in_trigger_loop NULL;用用户变量做简易“递归锁”。注意MySQL 8.0 引入了innodb_lock_wait_timeout参数但触发器内的锁等待超时是全局的无法单独配置。所以所有触发器内的 DML 操作必须确保目标表有合适的索引且 WHERE 条件足够精确。宁可多建一个联合索引也不要让触发器在锁队列里排队。4. 实操过程与核心环节实现一个真实库存扣减触发器的完整构建4.1 需求还原与表结构设计从模糊描述到可执行DDL我们以电商系统中最核心的“下单扣库存”场景为例还原一个生产级触发器的诞生过程。原始需求描述很朴素“用户下单时要检查商品库存是否充足充足则扣减不足则拒绝”。但作为资深从业者我立刻追问并确认了五个关键细节这些细节直接决定了触发器的健壮性Q1库存不足时是静默失败返回错误给前端还是降级处理如改为预售→ 确认必须严格拒绝不允许降级。这是资损防控红线。Q2库存字段是实时扣减stock stock - order_qty还是状态标记is_in_stock 0→ 确认实时扣减且需支持负库存预警即允许短暂负值但要记录告警。Q3订单表和商品表是否在同一数据库跨库如何处理→ 确认同库表名为orders和products。Q4并发场景下如何避免超卖是靠数据库锁还是应用层分布式锁→ 确认必须由数据库保证不依赖应用层。Q5是否需要记录扣减日志用于对账和审计→ 确认需要但日志表inventory_logs是异步写入不在主事务中。基于以上我设计了最小可行表结构-- 商品表核心库存字段 CREATE TABLE products ( id BIGINT PRIMARY KEY AUTO_INCREMENT, sku VARCHAR(50) NOT NULL UNIQUE, name VARCHAR(200) NOT NULL, stock INT NOT NULL DEFAULT 0, -- 当前可用库存 reserved_stock INT NOT NULL DEFAULT 0, -- 已锁定但未确认的库存如已下单未支付 created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 订单主表 CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, status ENUM(created,paid,shipped,completed,cancelled) DEFAULT created, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 订单明细表关联商品和数量 CREATE TABLE order_items ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, product_id BIGINT NOT NULL, sku VARCHAR(50) NOT NULL, quantity INT NOT NULL DEFAULT 1, price DECIMAL(10,2) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (order_id) REFERENCES orders(id) ON DELETE CASCADE, FOREIGN KEY (product_id) REFERENCES products(id) );关键设计点说明products.stock是真实库存reserved_stock是预占库存两者分离避免支付失败后库存无法释放。order_items表通过product_id关联商品而非直接存sku确保数据一致性。所有时间字段统一用DATETIMECURRENT_TIMESTAMP规避时区问题。4.2 触发器逻辑推演从伪代码到可运行SQL的思维转换现在我们聚焦在order_items表的BEFORE INSERT触发器上。目标是在每一行订单明细插入前检查对应商品的stock - reserved_stock NEW.quantity满足则扣减reserved_stock不满足则报错。第一步写出清晰的伪代码逻辑1. 获取 NEW.product_id 对应的商品记录 2. 计算当前可用库存 stock - reserved_stock 3. 如果可用库存 NEW.quantity则 SIGNAL 错误 4. 如果可用库存 NEW.quantity则 SET NEW.reserved_stock_delta NEW.quantity 为后续更新准备 5. 可选记录一条扣减日志异步不在此触发器内第二步转换为 MySQL 触发器 SQL。注意几个实操要点必须用SELECT ... INTO将商品数据载入变量不能直接在IF中写子查询MySQL 触发器不支持变量名要加前缀且需在BEGIN后声明扣减操作不能在触发器里直接UPDATE products因为这是对触发表的修改会报错。正确做法是在触发器里计算好reserved_stock的新值然后在AFTER INSERT触发器里更新但AFTER不能改本表所以必须用BEFORESIGNAL 应用层重试或改用存储过程。等等这里出现矛盾了标准触发器无法在BEFORE INSERT中更新products表。怎么办这就是真实世界里的权衡。我给出两个生产环境验证过的方案方案A推荐BEFORE INSERT 应用层补偿触发器只做校验和信号抛出应用层捕获SIGNAL错误后立即重试最多3次或降级提示用户“库存紧张请稍后再试”扣减reserved_stock的操作放在应用层INSERT order_items成功后的UPDATE products SET reserved_stock reserved_stock ? WHERE id ?语句中利用数据库行锁保证原子性。方案B强一致性存储过程封装不用触发器改用存储过程sp_create_order_item过程内用START TRANSACTION包裹SELECT ... FOR UPDATE锁定商品行INSERTUPDATE这样能确保“查-扣”原子性且避免触发器的诸多限制。考虑到本例标题是“触发器”我们采用方案A并写出完整的BEFORE INSERT触发器DELIMITER $$ CREATE TRIGGER tr_order_items_before_insert BEFORE INSERT ON order_items FOR EACH ROW BEGIN DECLARE v_stock INT DEFAULT 0; DECLARE v_reserved_stock INT DEFAULT 0; DECLARE v_available_stock INT DEFAULT 0; -- 1. 查询商品当前库存和预占库存 SELECT stock, reserved_stock INTO v_stock, v_reserved_stock FROM products WHERE id NEW.product_id LOCK IN SHARE MODE; -- 加共享锁防止并发修改 -- 2. 计算可用库存 SET v_available_stock v_stock - v_reserved_stock; -- 3. 校验库存是否充足 IF v_available_stock NEW.quantity THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT CONCAT(商品ID , NEW.product_id, 库存不足当前可用, v_available_stock, 需, NEW.quantity); END IF; -- 4. 可选为应用层提供预占数量便于后续 UPDATE -- 这里不直接 UPDATE而是让应用层知道需要加多少 reserved_stock -- SET reserved_delta NEW.quantity; -- 用户变量不推荐改用返回值或日志 END$$ DELIMITER ;实操心得LOCK IN SHARE MODE是关键。它让SELECT语句对products表加共享锁阻止其他事务对该行执行UPDATE或DELETE直到本事务结束。这比SELECT ... FOR UPDATE加排他锁更轻量因为我们只读不写。但注意SHARE MODE不阻止其他事务也加SHARE MODE所以它只防写不防读正好符合我们的需求——多个并发下单请求可以同时读取库存但只要有一个开始UPDATE reserved_stock其他请求就会被阻塞从而串行化扣减操作。4.3 部署与验证不只是“能跑”更要“跑得稳”写完触发器绝不等于完工。我坚持一套四步验证法Step 1单条语句基础验证-- 插入一条正常订单明细 INSERT INTO order_items (order_id, product_id, sku, quantity, price) VALUES (1, 1, SKU001, 2, 99.00); -- 应成功 -- 插入一条超库存订单明细 INSERT INTO order_items (order_id, product_id, sku, quantity, price) VALUES (2, 1, SKU001, 1000, 99.00); -- 应报错商品ID 1 库存不足...Step 2并发压力模拟用sysbench或简单脚本启动 100 个线程同时对同一商品 ID 执行INSERT。观察是否有超卖products.reserved_stock被扣成负数错误率是否在合理范围5%数据库 CPU 和锁等待时间是否飙升Step 3异常路径覆盖测试product_id不存在的情况触发器内SELECT INTO会返回NULL需加IF v_stock IS NULL THEN SIGNAL ... END IF;测试quantity 0的非法值测试INSERT ... SELECT批量插入触发器会为每一行执行一次需确认性能。Step 4上线灰度与监控先在测试库开启general_log记录所有触发器执行日志上线后在生产库开启performance_schema监控SELECT * FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE %tr_order_items_before_insert%;关注AVG_TIMER_WAIT平均耗时和COUNT_STAR执行次数设置告警当触发器错误率ERRORS字段超过 1%/分钟立即通知 DBA。5. 常见问题与排查技巧实录那些文档里不会写的血泪教训5.1 “触发器不执行”——不是代码错了是姿势不对这是最高频的求助问题。用户哭诉“我明明写了CREATE TRIGGER也SHOW TRIGGERS看到了但 INSERT 就是不触发” 我的排查清单如下检查项常见原因验证命令解决方案表名拼写ON table_name写成ON table_name_bak或大小写不一致Linux 下敏感SHOW CREATE TABLE table_name;确保ON后的表名与SHOW CREATE TABLE输出完全一致触发时机需求是“插入后更新”却写了BEFORE INSERTSHOW TRIGGERS LIKE table_name;SHOW TRIGGERS输出的Event列显示INSERTTiming列显示BEFORE/AFTER权限缺失创建触发器的用户没有TRIGGER权限SHOW GRANTS FOR CURRENT_USER;GRANT TRIGGER ON database_name.* TO user%;SQL_MODE 限制开启了STRICT_TRANS_TABLES触发器内SET NEW.column NULL导致主 SQL 失败SELECT sql_mode;在触发器内显式处理 NULL或调整 SQL_MODE不推荐独家技巧在触发器开头加一句INSERT INTO debug_log (msg, ts) VALUES (trigger fired, NOW());并确保debug_log表存在。如果这条日志没出现说明触发器根本没被调用如果出现了说明是触发器内部逻辑问题。这是最朴实无华却百试不爽的定位法。5.2 “触发器报错Table xxx is read only”——MySQL 的隐形枷锁这个错误通常出现在主从复制架构中。从库Slave默认是只读的read_onlyON而触发器如果尝试UPDATE其他表就会触发此错误。但奇怪的是BEFORE INSERT触发器里SET NEW.column却不会报错。原因在于SET NEW.column是修改即将插入的行数据不涉及表的读写而UPDATE other_table是对另一张表的写操作从库禁止一切写操作。解决方案只有两个方案1推荐关闭从库触发器在从库上执行SET GLOBAL sql_log_bin OFF;然后DROP TRIGGER trigger_name;。因为从库只需同步主库的 DML不需要执行触发器逻辑。方案2用SQL_LOG_BIN0临时关闭二进制日志在触发器内SET SQL_LOG_BIN 0; UPDATE ...; SET SQL_LOG_BIN 1;。但这会导致该UPDATE不写入 binlog主从数据不一致强烈不推荐。5.3 “触发器导致死锁”——锁等待的连锁反应死锁日志通常长这样LATEST DETECTED DEADLOCK ------------------------ 2023-10-01 12:00:00 0x7f8b1c000b20 *** (1) TRANSACTION: TRANSACTION 12345, ACTIVE 10 sec inserting mysql tables in use 2, locked 2 LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s) *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 123 page no 456 n bits 72 index PRIMARY of table db.products trx id 12345 lock_mode X locks rec but not gap waiting这表示事务1在等待products表的主键锁。结合触发器代码大概率是SELECT ... FOR UPDATE或UPDATE语句锁住了商品行而另一个并发事务也在锁同一行。我的根治三步法精简锁范围把SELECT * FROM products WHERE id ?改成SELECT stock, reserved_stock FROM products WHERE id ?只查必要字段减少锁持有时间缩短事务生命周期确保触发器内所有 SQL 都在同一个事务中快速完成避免在触发器里调用耗时存储过程应用层重试捕获死锁错误Deadlock found when trying to get lock让应用层自动重试 2-3 次成功率可达 99.9%。5.4 “触发器性能骤降”——慢查询的隐形推手某次线上事故一个AFTER INSERT触发器平时执行 0.5ms某天突然飙到 500ms拖垮整个订单服务。EXPLAIN发现触发器里一句SELECT COUNT(*) FROM large_log_table WHERE date 2023-01-01没走索引全表扫描了 2000 万行。这类问题的特征是触发器本身逻辑简单但依赖的查询对象表、视图、函数发生了变化。排查口诀“查表、查索引、查数据量”。查表SHOW TABLE STATUS LIKE large_log_table;看Rows字段是否暴增查索引SHOW INDEX FROM large_log_table;看date字段是否有索引是否失效Cardinality为 0查数据量SELECT COUNT(*) FROM large_log_table WHERE date 2023-01-01;实测查询耗时。解决方案不是优化触发器而是重构依赖给 large_log_table
从文本行创建Stream的实战指南与避坑详解)
