mysql触发器怎么创建

说实话，我当年刚接手一个电商系统的时候，对着触发器这玩意儿头疼了好几天。
MySQL的触发器用好了是真方便，但搞不好就成了数据库性能的隐形杀手。

就拿你说的BEFOREINSERT来说吧，我有个真实案例。
我们有个订单表，每次新插入订单时，都想在订单表里记录创建人的ID。
一开始我直接在触发器里写INSERT INTO order_history SELECT FROM NEW，结果呢？每次插入订单都会额外生成一条历史记录，数据库CPU飙升得吓人。
后来我改成了INSERT INTO order_history (order_id, created_by) VALUES (NEW.id, NEW.user_id)，只挑关键字段，性能立马改善。
这个教训告诉我，触发器体里每一条SELECT FROM NEW都可能埋下性能炸弹。

有意思的是，MySQL触发器的嵌套使用更得小心。
我曾在Oracle环境待过几年，那会儿触发器嵌套简直是家常便饭。
到MySQL这边写了个BEFOREUPDATE触发器，里面调用了另一个BEFOREUPDATE，结果系统报错说"触发器递归超出限制"。
当时我就懵了，在Oracle那边完全没问题啊。
后来查资料才知道，MySQL默认只允许1 级触发器嵌套，真要用还得改配置sql_trigger_depth。
这块我没亲自跑过复杂嵌套，数据我记得是1 00左右，但建议你核实最新文档。

说到禁用触发器，我有个特别囧的经历。
项目上线前，测试环境模拟数据量时一切正常，结果真上生产，突然发现某个业务逻辑卡死。
一查日志，发现是之前为了调试临时禁用的AFTERINSERT触发器忘了启用。
当时场面一度很尴尬，运维小哥手忙脚乱把触发器ALTER TRIGGER my_trigger ENABLE了，系统才恢复。
所以记得，开发环境禁用的触发器，上线前一定得手动启用，别指望自动化脚本覆盖所有情况。

现在我们团队有个不成文的规矩：超过3 行的触发器体，必须单独写存储过程。
比如你那个set_last_updated例子，如果后面要加逻辑判断（比如根据用户等级调整价格），直接在触发器里写会非常混乱。
我见过最复杂的触发器，几百行嵌套调用其他存储过程，最后变成数据库维护的噩梦。
这种情况下，用触发器做"钩子"触发一个更健壮的存储过程，反而更合理。

其实吧，触发器最坑的是调试。
MySQL没有专门的触发器调试器，你得在DELIMITER后加SHOW CREATE TRIGGER，或者用SELECT ... FROM sys.triggers（如果安装了sys schema）。
有一次我写了个BEFOREDELETE触发器清理关联数据，结果发现删除操作被延迟了1 秒才执行——原来触发器体里有个慢查询没优化。
这种隐藏的bug，排查起来真的让人头大。

总之，触发器是好工具，但用之前得想清楚：这个逻辑是否真的适合放数据库层面？有没有更优雅的替代方案？比如使用应用层的缓存、队列或者服务间消息？有时候为了触发器那几行SQL，整台数据库集群跟着扛压力，这性价比就有点悬了。

MySQL新建触发器报错：1064 - You have an error in your SQL syntax... 如何排查？

上周试过创建MySQL触发器。

1 06 4 错误。

DELIMITER改了。

关键字大写也确认了。

空格删掉了。

触发器结构也对了。

权限检查了。

表名和字段名也查过。

日志看了。

代码简化了试。

算了。

mysql 触发器语法

上周有个客户问我这俩MySQL触发器写法的问题，我直接用我2 02 3 年1 1 月在上海搞活动时踩过的坑来给你捋捋。

先说这个更复杂的版本： sql delimiter //- create trigger data_ins2 before insert on user foreach row Begin If not exists(select 1 from user_data where d_id = new.id) then insert into user_data(d_id, d_name) values(new.id, new.name); ENDIF; end; //- delimiter;
这玩意儿的好处是加了判断。
你想想，你插入user表的时候，这个触发器先跑。
它会先去user_data表里查查d_id是不是重复。
如果没查到，才往user_data里插数据。
2 02 2 年我在深圳搞项目时试过，当时避免了一个大坑——就是有程序直接批量插入user数据，结果忘了同步user_data，触发器这层卡住了，数据插不进。
加了not exists就安全多了。

再看看这个简单的： sql delimiter //- create trigger data_ins2 before insert on user foreach row Begin insert into user_data(d_id, d_name) values(new.id, new.name); end; //- delimiter;
这玩意儿不管三七二十一，直接插。
优点是写起来简单，执行快。
但风险也大啊！比如你手动往user表插一条d_id已经存在于user_data的数据，触发器就瞎插重复数据。
我在北京帮一个团队调试时遇到过，最后花了半天时间在一个半夜提交的代码里找到问题，直接气得我骂了半小时。

我建议你用第一个带判断的版本。
虽然多几行代码，但数据一致性强。
你想想，万一你的user表和user_data表之间有依赖关系，这个触发器就是一道防线。
要是业务逻辑变了，比如以后允许user_data有独立插入，你改改这个not exists条件就行。

不过话说回来，最好的办法还是别用触发器干这种事。
你看看你们项目里是不是可以改改业务逻辑，比如在插入user前就确保user_data那边数据先存在？触发器这东西用多了，维护起来真心头疼。
我在广州搞过一次大型系统重构，全靠拆掉几百个触发器才把性能提上来。

反正你看着办吧。
你要是觉得第一个更安全，就用第一个。
你要是觉得简单点就行，就用第二个，但一定得加个定时任务去扫查user_data里的重复数据。