面试必问：什么是触发器？3分钟讲透触发器的本质与用法

大家好呀，我是你们的老朋友小米，今年31岁，一个依然还在社招市场摸爬滚打的程序员。最近，我去面试了一家金融科技公司，遇到了一道挺有意思的数据库题，面试官看着我笑了笑，说：

“来，聊聊触发器吧，你觉得它是干嘛的？平时用在什么场景？MySQL里有哪些触发器呢？”

听到这题的瞬间，我心里咯噔一下。触发器这个东西，说熟也熟，说陌生也陌生。因为在日常开发中，我们可能更常接触 SQL语句、存储过程、索引优化，而触发器呢，往往像个“隐藏高手”，不常出手，但一旦用到，就能解决一些非常独特的问题。

今天，我就借着这个故事，把触发器的来龙去脉、应用场景，还有MySQL里的具体类型，好好聊一聊。希望能帮到正在准备面试的你们，也顺便复盘一下我自己的学习过程。

什么是触发器？像“埋伏”的程序员

我给触发器打个比喻：

它就像一位“埋伏在暗处的程序员”，盯着你的数据库表，一旦有动作发生，比如有人新增一条记录、修改了一条数据、或者删除了一行，它就会立刻跳出来，按照事先设定的逻辑，把该做的事情做完。

更正式一点的解释是：

触发器（Trigger） 是一类特殊的存储程序，它与表相关联，在表上发生 INSERT、UPDATE 或 DELETE 操作时自动执行。

它跟存储过程有点像，区别在于：

• 存储过程需要我们主动调用，比如执行 CALL my_proc()；
• 而触发器是被动执行的，不用手动触发，只要满足条件，就会自动生效。

这就像公司里有两种人：

• 存储过程 = 你去喊小王：“来，帮我写个日报！”
• 触发器 = 小王盯着考勤机，只要你迟到，他就自动把你记在小本本上。

触发器的使用场景：它出手时往往是关键时刻

面试官问到“触发器的使用场景”，我当时就分享了几个经典案例。

1、自动生成日志

想象一下，你们公司有个用户表 users，只要有人修改了用户信息，比如更改了手机号或者邮箱，你可能需要记录一份操作日志。

• 这时候写触发器就很方便：只要 UPDATE 一下 users 表，触发器就会自动往 user_log 表插入一条日志。

2、数据一致性校验

有些规则不能完全依赖前端或者业务代码，比如工资不能为负数、库存不能为负数。

• 可以在触发器里加逻辑：如果发现不符合要求的数据，直接报错或者拦截。

3、复杂的级联操作

虽然数据库有外键，但有时候外键约束不够灵活，或者涉及到一些计算逻辑。

• 比如删除一张订单的时候，需要自动更新库存表的数量、财务表的金额，这些都可以通过触发器实现。

4、审计和安全控制

有些公司需要追踪谁改了什么数据，触发器可以帮助我们记录“谁在什么时候对表做了什么操作”，方便审计。

5、衍生字段的计算

例如，插入销售记录时，触发器可以自动计算总价，填充到 total_amount 字段里，避免应用层反复写逻辑。

当我说到这些场景的时候，面试官点了点头，说：“不错，说明你是真的用过，而不是只背了定义。”

技术大厂，跳板机机会→ 前端-后端-测试，待遇还不错，感兴趣可以试试~

MySQL中的触发器：六大类型

聊完概念和场景，接下来就是面试最关键的一问：MySQL里有哪些触发器？

MySQL提供的触发器一共有六种，核心就是两条线：

• 一条线是动作类型：INSERT、UPDATE、DELETE；
• 另一条线是执行时机：BEFORE、AFTER。

组合一下，就变成了六种：

1、BEFORE INSERT—— 插入数据前触发

可以用来检查数据是否合法，比如手机号是不是11位，不合法就报错。

2、AFTER INSERT—— 插入数据后触发

常用于写入日志，比如有人新增了一条订单，就在日志表里记一笔。

3、BEFORE UPDATE—— 更新数据前触发

可以拦截非法修改，比如不允许把工资从正数改成负数。

4、AFTER UPDATE—— 更新数据后触发

常用于记录历史版本，比如把旧数据存到一张历史表里。

5、BEFORE DELETE—— 删除数据前触发

可以阻止某些重要数据被删掉，比如管理员账号。

6、AFTER DELETE—— 删除数据后触发

常用于级联操作，比如删除订单后，自动更新库存表的数量。

所以记住口诀：

三种动作 × 两个时机 = 六种触发器。

面试官听到这里，笑着说：“很好，这个答案算满分。”

触发器的利与弊：一把双刃剑

不过，触发器并不是万能的。它很强大，但也很危险，滥用会带来麻烦。

优点：

• 可以保证数据一致性；
• 减少应用层逻辑；
• 自动化处理一些复杂逻辑。

缺点：

• 逻辑分散在数据库里，调试和维护不方便；
• 触发器过多会导致性能问题，尤其是高并发场景；
• 程序员可能忘了有触发器，导致“明明没写代码，为什么数据会变？”的疑惑。

我面试的时候也补充了一句：

“触发器适合用在强规则和核心数据一致性的场景，但不能滥用。大部分业务逻辑还是应该放在应用层，而不是数据库里。”

面试官听了以后，点了点头，算是认可我的观点。

故事：一个触发器引发的“生产事故”

说到这里，我忍不住跟大家分享一个曾经踩过的坑。

我之前在一家电商公司，某个同事写了一个触发器：每当有人删除订单，就自动把库存加回来。

听起来挺合理的，但后来线上出了个大bug：

• 有个用户下单后付款失败，系统自动删除了订单；
• 触发器触发，把库存加了回去；
• 结果库存变成负数！因为这批货本来就没货了，强行“凭空加回”了一件。

最后搞得仓库里明明没有货，系统却显示还有库存，导致客服被骂惨了。

这件事让我记住了一句话：

触发器是利器，但一定要谨慎使用，别让它成为“背锅侠”。

如何在面试中回答触发器的问题？

如果你也在准备社招面试，遇到类似问题，可以这样组织答案：

• 先定义：触发器是与表关联的存储程序，能在 INSERT、UPDATE、DELETE 时自动触发。
• 再说场景：举3~4个典型应用，比如日志记录、数据校验、级联操作。
• 然后列类型：六种触发器，三动作 × 两时机。
• 最后补充利弊：触发器很强大，但要谨慎使用。

这样的答案逻辑清晰，面试官听着会觉得你不光懂，还能结合实践思考。

总结

写到这里，我觉得触发器就像我们程序员的人生。

有些人主动出击（像存储过程），有些人默默守护（像触发器）。

虽然它不常出现在大家的日常开发里，但在关键场景下，触发器能帮我们守住数据的底线。

如果你下次去面试，遇到“什么是触发器”这种问题，不要慌，就按照“定义—场景—类型—利弊”的逻辑回答，稳稳拿下这道题。

希望我的这次经历，能让你在面试的时候少掉几根头发，甚至还能让面试官对你刮目相看。

END

我是小米，一个喜欢分享技术的31岁程序员。如果这篇文章对你有帮助，记得点个赞或者转发给正在准备面试的朋友呀。

下次面试别怕，咱们一起拿下更多offer！

——转载自：软件求生