触发器中不能用 NOW() 做实时过期判断，因其返回语句开始时刻时间戳，同一条多行语句中所有行的 NOW() 值相同，无法实现秒级精确过期判定。
触发器里不能用 NOW() 做实时过期判断
SQL 触发器运行在语句执行上下文中，NOW() 返回的是语句开始时刻的时间戳，不是“当前真实时间”。如果一条 UPDATE 涉及上千行，所有行看到的 NOW() 都一样——根本没法做精确到秒的过期判定。
常见错误现象：用户在 BEFORE UPDATE 里写 IF updated_at ，结果批量更新时部分本该过期的记录没被拦截。
- 真正需要过期控制的场景（如优惠券、临时 token），应把判断逻辑移出触发器，放到应用层或调度任务中
- 触发器只适合做“强约束型”检查（比如字段非空、状态流转合法性），不适合带时间漂移敏感的业务规则
- 若坚持在数据库侧做，改用
CURRENT_TIMESTAMP（更稳定）且仅用于记录时间，不用于比较
用事件调度器（EVENT）替代轮询式清理脚本
很多人用外部 cron 调 DELETE FROM orders WHERE status = 'draft' AND created_at ，但容易因网络抖动、权限变更、脚本挂起导致漏删。MySQL 自带的 EVENT 更可靠，且能精确控制执行时机。
使用前提：确保 event_scheduler 已开启（SET GLOBAL event_scheduler = ON;），否则事件永远不会触发。
- 事件名必须唯一，建议带业务前缀，如
ev_cleanup_expired_tokens - 时间单位只支持
SECOND/MINUTE/HOUR/DAY/WEEK/MONTH/YEAR，不支持INTERVAL 30 MINUTE SECOND这种混合写法 - 事件体里不能有事务控制语句（
START TRANSACTION等），但DELETE本身是自动事务，无需额外包装 - 示例：
CREATE EVENT ev_cleanup_expired_tokens<br>ON SCHEDULE EVERY 1 HOUR<br>DO DELETE FROM tokens WHERE expires_at
DELETE + LIMIT 在大表上会锁表太久
直接 DELETE FROM logs WHERE created_at 可能锁住整个表几秒甚至几分钟，阻塞线上写入。尤其在 MySQL 5.7+ 默认 innodb_lock_wait_timeout=50 下，应用很容易报 Lock wait timeout exceeded。
正确做法是分批删除，但触发器和事件都不支持循环，只能靠调度任务配合限流逻辑。
- 每次删不超过 1000 行，用
DELETE FROM logs WHERE created_at - 必须加
ORDER BY（推荐主键），否则LIMIT行为不可预测，可能重复删或漏删 - 删除后检查
ROW_COUNT()，等于 0 就停，不等于 0 就继续下一轮（需外部脚本或存储过程驱动） - 避免在高峰期执行，可在事件里加时间判断：
IF HOUR(NOW()) BETWEEN 2 AND 4 THEN ... END IF;
触发器无法响应调度事件，别混用两套机制
有人想让事件触发后自动调触发器，比如“每小时清一次 token，清完立刻更新统计表”，于是给 tokens 表建 AFTER DELETE 触发器去改 stats 表。问题在于：事件执行的 DELETE 是在系统用户上下文，可能没权限操作其他表；更关键的是，触发器在事件内部执行，一旦失败，整个事件就中断，后续清理不会继续。
典型错误：事件里删数据，同时依赖触发器维护索引表，结果某次触发器里写了不存在的列，事件静默失败，统计越来越不准。
- 调度任务（EVENT）和触发器（TRIGGER）属于两个隔离层级，不要指望它们协同完成原子性动作
- 统计类更新，应该由事件自己完成：
DO BEGIN DELETE ...; UPDATE stats SET count = (SELECT COUNT(*) FROM tokens); END - 如果真要解耦，用应用层消息队列，而不是在数据库里搞跨机制联动
事情说清了就结束。最常被忽略的是：事件调度器默认关闭，且没有错误日志输出——它静默失败时，你根本不知道数据还在那里躺着。
