触发器是一种特殊的存储过程,不像存储过程需要显示调用,触发器通过监控表事件(增删改操作)自动触发某条 sql 的执行,可以用于购物车加购后库存减少等场景。
DELIMITER $$
CREATE
/*[DEFINER = { user | CURRENT_USER }]*/
TRIGGER `dbname`.`trigger` BEFORE/AFTER INSERT/UPDATE/DELETE
ON `dbname`.`<Table Name>`
FOR EACH ROW BEGIN
-- 触发的 sql 动作
END$$
DELIMITER ;
触发事件类型 | new/old使用 |
---|---|
INSERT事件 | 没有 old,只有 new,new 表示将要(插入前)或者已经增加(插入后)的数据 |
UPDATE事件 | 既有 old 也有 new,old 表示更新之前的数据,new 表示更新之后的数据 |
DELETE事件 | 没有 new,只有 old,old 表示将要(删除前)或者已经被删除(删除后)的数据 |
SQL 语句:
SHOW TRIGGERS;
触发器不能修改,只能删除,删除 sql 语句:
DROP TRIGGER triggerName;
触发器事件跟触发器中的 SQL 语句是原子性的(要么同时执行,要么同时不执行),这样保证了数据的完整性。
1)只适合用于并发不高的管理系统中用,如果是面向用户的高并发应用,则不能使用,因为大部分的 web 应用瓶颈都在 DB,把耗时的服务做成 Scale Out,这种情况下,肯定不会使用存储过程;而如果只是一般的应用,DB 没有性能上的问题,在适当的场景下,也可以使用存储过程。
2)存储过程的致命伤在于移植性,存储过程不能跨库移植,比如事先是在mysql数据库的存储过程,考虑性能要移植到oracle上面那么所有的存储过程都需要被重写一遍。
3)触发器不推荐使用,难以开发和维护,且可以被事务代替,触发操作能在业务层解决就在业务层解决,否则很难维护,而且容易产生死锁。
原文:https://www.cnblogs.com/aizen-sousuke/p/11965908.html