MySQL触发器中获取“上一次更新时间”只能通过OLD.updated_at读取当前行更新前的值，不可查询本表；限制5秒内重复更新需用UNIX_TIMESTAMP(NOW())-UNIX_TIMESTAMP(OLD.updated_at)<5配合SIGNAL抛错，且要求updated_at字段存在、非NULL并启用ON UPDATE CURRENT_TIMESTAMP。
触发器里怎么获取上一次更新时间
必须依赖表中已存在的时间戳字段（比如 updated_at），不能在触发器里凭空查“上次修改是什么时候”。MySQL 不支持在 BEFORE UPDATE 触发器中直接对本表做 SELECT（会报错 ERROR 1442），所以得换思路：用 AFTER UPDATE 记录日志，或把判断逻辑前置到应用层——但如果你坚持用触发器，唯一可行的是在触发器里读取当前行的旧值：OLD.updated_at。
注意：OLD 只在 UPDATE 触发器中可用，且仅反映本次更新前该行的值。它不是“历史最新更新时间”，只是“这次要被覆盖掉的那个时间”。所以真正要限制“5秒内不能重复更新”，得靠这个旧值和 NOW() 对比：
IF (UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(OLD.updated_at)) < 5 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Update too frequent'; END IF;
MySQL 8.0+ 的 BEFORE UPDATE 触发器能用 SIGNAL 吗
能，但有硬性前提：必须是 BEFORE UPDATE，且只能在存储过程、函数、触发器或事件中用 SIGNAL 中断执行。低版本 MySQL（如 5.6）不支持 SIGNAL，得改用制造一个非法操作来抛错，比如向不存在的表插入数据——但这不推荐，错误信息不可控。
常见踩坑点：
-
SIGNAL后触发器立即终止，但事务仍处于活跃状态，需由上层决定是否回滚 - 如果表没定义
updated_at字段，或者允许为NULL，OLD.updated_at可能为空，UNIX_TIMESTAMP(NULL)返回NULL，导致整个表达式判 false——不会抛错，但限制失效 - 务必确保
updated_at在每次更新时真实刷新（比如用ON UPDATE CURRENT_TIMESTAMP），否则OLD.updated_at滞后，规则形同虚设
为什么不在应用层做频率校验而要用触发器
触发器是最后防线：当存在多服务、直连数据库的脚本、或绕过 ORM 的原始 SQL 更新时，应用层校验会漏掉。但代价明显——性能损耗、调试困难、主从延迟下时间判断失准。
实际部署要注意：
- 时间函数用
NOW()而非SYSDATE()，后者返回函数执行时刻，受语句执行耗时影响；NOW()是语句开始时间，更稳定 - 跨服务器部署时，各节点系统时间必须 NTP 同步，误差超过阈值（如 2 秒）会导致误拦或放行
- 高频写入场景下，触发器增加单条 UPDATE 的延迟，压测时容易暴露瓶颈
PostgreSQL 怎么写等效逻辑
PostgreSQL 没有 SIGNAL，但可用 RAISE EXCEPTION 达到同样效果，且支持在 BEFORE UPDATE 中直接查询本表（MySQL 禁止的事，PG 允许）：
IF (EXTRACT(EPOCH FROM NOW()) - EXTRACT(EPOCH FROM OLD.updated_at)) < 5 THEN RAISE EXCEPTION 'Update too frequent'; END IF;
不过更稳妥的做法是查最新记录（防并发更新覆盖时间戳）：
PERFORM 1 FROM your_table WHERE id = NEW.id AND updated_at > NOW() - INTERVAL '5 seconds';
如果查到结果，说明 5 秒内已有更新，再 RAISE EXCEPTION。这比只依赖 OLD.updated_at 更抗并发，但也带来额外查询开销。
真正难处理的从来不是语法，而是“谁在什么时候改了哪一行”——时间戳字段本身是否可信、是否被业务代码跳过更新、是否被批量脚本清空，这些比触发器怎么写更容易让整套机制失效。
