MySQL触发器的使用

触发器可以在执行语句前或执行后触发其他 sql 代码运行。触发器可以读取触发语句改变了哪些数据，但是没有返回值。因此可以使用触发器加强业务逻辑的约束而不需要在应用程序写对应的代码。

从上述描述可以看到，触发器可以简化应用程序的逻辑并且可以提升性能，这是因为使用触发器减少了应用程序和服务端的交互次数。同时，触发器有助于完成自动更新归一化和统计数据。例如，我们可以使用触发器自动统计交易订单总金额，订单数及平均客单价。 然而，mysql 的触发器的应用场合也十分有限，如果你使用过其他数据库产品的触发器，不要以为 mysql 也能实现相同的功能，例如：

• 每个数据表的单一事件只能有一个触发器，也就是说对于 after insert 这样的事件来说，不能同时有超过1个的触发器。
• mysql 只支持行级别的触发器，也就是只能按 for each row 这种方式使用触发而不是整个 sql 语句，这对于大量数据的操作而言会比较低效。mysql 的触发器只能按下面的形式编写：

?

1 2 3 4 5

create trigger 触发器名 before| after 触发事件 on 表名 for each row begin      执行语句列表; end

执行语句列表支持单条或多条语句，下面是一个多条语句的示例：

?

1 2 3 4 5 6 7 8 9 10 11

delimiter $$ create trigger user_create_log after insert on t_users for each row begin declare log_info varchar (40) character set utf8; declare description varchar (20) character set utf8;#后面发现中文字符编码出现乱码，这里设置字符集 set description = " is created" ; set log_info = concat(new.user_name, description);     #函数concat可以将字符串连接 insert into logs(log) values (log_info); end $$   delimiter ;

• 触发器可能导致服务端实际执行的工作不可预测，一个简单的语句可能导致服务端做大量不可见的工作。例如，如果一个触发器更新了 一个相关的表，可能导致受影响的行数加倍。
• 触发器难以调试，并且一旦引入了触发器，很难分析性能瓶颈。
• 触发器会导致潜在的锁等待和死锁。如果触发器失败了，源查询也会失败。如果没有意识到触发器的存在，这类玩呢提很难发现。

大多数限制中，最大的限制是 for each row 的设计，这有时候导致触发器没法用于维护统计和缓存表，这是因为这可能很慢。使用触发器的主要理由是相比定时同步更新，触发器可以一致保持数据的一致性。 触发器也没法保证原子性。例如，更新 myisam 数据表的触发器在源 sql 语句出错后，无法回滚。而且，触发器自身也可能都只错误。如果我们使用了 after update 基于 myisam 数据表去更新另一个表。如果触发器有个导致第二张表操作失败的错误，那对于第一张表的操作不会回滚。

innodb 的触发器相关的操作，包括源语句都在同一个事务中，因此是满足原子性的。然而，如果使用innodb 的触发器去与另一张表校验数据一致性的时候，这个时候如果不小心的话可能导致不正确的结果。例如，假设需要使用触发器模拟外键，可以使用 before insert触发器验证另一张表是否存在对应的记录，但是如果在触发器读取另一张表数据的时候不使用 select for update的话，则由于并发性性问题可能导致错误的结果。 虽然触发器有些缺陷，但是这并不意味着不能用。相反，触发器本身也是有用的，尤其是对于约束，系统维护任务和保持统计数据保持最新。

也可以使用触发器记录数据行的变化。这样即便是离线手动操作数据库的记录（如修复错误数据）也能够被记录下来。但是，需要注意的是对于往其他自增主键表插入数据时要小心，这对于复制性的语句表现会有问题，因为自增值对于两个相同的副本值并不同。

结语：

触发器在有限的场合能够发挥其优势，比如统计数据、数据表变更日志等。但是也会有一些缺陷，比如大数据量的更新由于逐行触发，会降低效率。还有就是，myisam 引擎无法保障原子性。因此，要根据应用场景是否要是有触发器。

以上就是mysql触发器的使用的详细内容，更多关于mysql触发器的资料请关注服务器之家其它相关文章！

原文链接：https://juejin.cn/post/6964737836339855374