不能靠触发器限制敏感字段更新频率，因其不支持会话级或时间窗口计数；需借助独立日志表+current_user()+唯一索引实现，或优先采用应用层redis滑动窗口限流。
不能靠触发器限制敏感字段的更新频率——它天然不支持会话级、时间窗口维度的计数，强行做会导致逻辑错乱或直接报错。
BEFORE UPDATE 触发器无法统计“每分钟改了多少次”
触发器是行级、语句级执行单元，不是会话级守卫。一个 UPDATE users SET email='x' WHERE id IN (1,2,3) 会触发一次 BEFORE UPDATE，但里面的 OLD/NEW 是逐行可用的，你没法在触发器里可靠地知道“这个用户今天第几次动 email”。更麻烦的是：
- 触发器内禁止对当前表做
SELECT COUNT(*)（报错ERROR 1442） - 也不能在触发器里读写同一张表的计数字段（比如加个
email_update_count列再自增） - 想用临时表或变量存状态？MySQL 触发器不支持跨语句共享变量，每次触发都是干净上下文
CURRENT_USER() + 日志表 + 唯一索引是唯一可行路径
真要防敏感字段高频修改（比如 email、phone），必须把计数逻辑外移，且依赖数据库原子性。典型做法：
- 建一张轻量日志表：
CREATE TABLE email_update_log (user_name VARCHAR(128), op_time TIMESTAMP(3) DEFAULT CURRENT_TIMESTAMP(3), PRIMARY KEY (user_name, op_time)) ENGINE=InnoDB - 在
BEFORE UPDATE触发器里执行：INSERT INTO email_update_log (user_name, op_time) VALUES (CURRENT_USER(), NOW(3)) - 查最近窗口次数：
SELECT COUNT(*) FROM email_update_log WHERE user_name = CURRENT_USER() AND op_time > DATE_SUB(NOW(3), INTERVAL 1 MINUTE) - 超限就
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Email update too frequent'
注意：主键必须是 (user_name, op_time)，且 op_time 要用 NOW(3)（毫秒级），否则高并发下时间戳重复，唯一约束失效。
为什么别在 UPDATE 触发器里查当前表的变更历史
常见错误是想在触发器里写：SELECT COUNT(*) FROM users WHERE email_updated_at > DATE_SUB(NOW(), INTERVAL 5 MINUTE)——这会直接触发 ERROR 1442。因为：
- MySQL 禁止触发器中访问正被修改的表（哪怕只是
SELECT） - 就算绕开（比如用存储函数封装），函数内查表仍可能隐式激活其他触发器，链式调用极易失控
-
users表本身没存操作者信息，CURRENT_USER()和行数据无关，无法关联到具体哪次改的是谁
生产环境优先用应用层限流或账号级配额
触发器方案虽能落地，但代价高：每次更新多一次 INSERT、多一次 SELECT、索引压力大、还容易因时钟漂移或事务回滚导致日志表脏数据。更合理的选择是：
- 对关键字段更新接口，在应用层用 Redis 做滑动窗口计数（如
INCRBY email_update:uid_123 1+EXPIRE） - 若要求强一致（如金融类实名认证），改用独立计数表 +
INSERT ... ON DUPLICATE KEY UPDATE原子写入 - 直接设 MySQL 用户级配额：
ALTER USER 'app_user'@'%' WITH MAX_UPDATES_PER_HOUR 30，虽不精确到字段，但能快速压住刷量行为
真正难处理的不是“怎么写触发器”，而是“怎么让多个服务实例看到同一个计数视图”——只要没走数据库原子写，任何内存缓存、本地变量、甚至 Redis 的 INCR 都可能在故障时失准。
