共计 1732 个字符，预计需要花费 5 分钟才能阅读完成。
触发器能够在执行语句前或执行后触发其余 SQL 代码运行。触发器能够读取触发语句扭转了哪些数据，然而没有返回值。因而能够应用触发器增强业务逻辑的束缚而不须要在应用程序写对应的代码。
从上述形容能够看到，触发器能够简化应用程序的逻辑并且能够晋升性能，这是因为应用触发器缩小了应用程序和服务端的交互次数。同时，触发器有助于实现自动更新归一化和统计数据。例如，咱们能够应用触发器主动统计交易订单总金额，订单数及均匀客单价。然而，MySQL 的触发器的利用场合也非常无限，如果你应用过其余数据库产品的触发器，不要认为 MySQL 也能实现雷同的性能，例如：
每个数据表的繁多事件只能有一个触发器，也就是说对于 AFTER INSERT 这样的事件来说，不能同时有超过 1 个的触发器。
MySQL 只反对行级别的触发器，也就是只能按 FOR EACH ROW 这种形式应用触发而不是整个 SQL 语句，这对于大量数据的操作而言会比拟低效。MySQL 的触发器只能按上面的模式编写：
CREATE TRIGGER 触发器名 BEFORE|AFTER 触发事件
ON 表名 FOR EACH ROW
BEGIN
执行语句列表;END
执行语句列表反对单条或多条语句，上面是一个多条语句的示例：
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 setwww.sangpi.com 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 引擎无奈保障原子性。因而，要依据利用场景是否要是有触发器。