oracle触发器可实现单用户每分钟修改频率限制，但必须用before update for each row触发器、以new.updated_at为时间基准计算窗口、配合user_id+updated_at复合索引，否则将漏判、锁表或全表扫描。
直接说结论：Oracle 触发器能做单用户每分钟修改频率限制，但必须用 BEFORE UPDATE FOR EACH ROW + 显式时间窗口计算 + 复合索引，否则查不到刚改的行、漏判、锁表或全表扫描。
这不是“能不能”的问题，而是“怎么写才不翻车”的问题。下面分三块说清关键动作。
为什么不能用 NOW() 或 SYSDATE 做时间判断
Oracle 里没有 NOW()，常用 SYSDATE，但它返回的是语句开始时间，不是当前实时时间。更麻烦的是：在 BEFORE UPDATE 触发器中，你查不到本事务内尚未提交的其他修改 —— 比如用户1秒内连改3条记录，第2、3次触发时子查询查不到前两次的变更（因为还没 COMMIT），导致限流失效。
解决办法只有一条：用 NEW.updated_at 字段（必须存在且被赋值）作为“本次操作发生时间”，再往前推60秒查历史：
-
SELECT COUNT(*) FROM posts WHERE user_id = :NEW.user_id AND updated_at > :NEW.updated_at - 60/86400（注意：Oracle 时间单位是天，60秒 =60/86400） - 确保
updated_at在 UPDATE 语句里被显式设为SYSDATE，不能依赖触发器自己赋值（否则循环依赖） - 别用
INTERVAL '60' SECOND，Oracle 11g 及以前版本对函数索引支持弱，容易走全表扫描
必须建的索引和字段约束
没索引=每次 UPDATE 都全表扫，QPS 过百就卡死。别信“加了 WHERE 就自动走索引”这种说法。
执行这条建索引语句：
CREATE INDEX idx_user_updated ON posts (user_id, updated_at);
同时确认：
-
user_id是 NOT NULL，否则索引可能失效 -
updated_at类型是DATE或TIMESTAMP，别用VARCHAR2存时间字符串 - 如果表有分区（比如按月分区），确保查询能落到单个分区，否则跨分区扫描照样慢
触发器里怎么抛错才算真正中断操作
Oracle 不支持 MySQL 那种 SIGNAL，也不像 PostgreSQL 能直接 RAISE EXCEPTION。它靠 RAISE_APPLICATION_ERROR 中断，但必须满足两个条件：
- 错误号必须在 -20000 到 -20999 范围内（比如
-20001） - 必须写在
BEFORE触发器里，AFTER触发器抛错无法回滚已执行的 DML
示例片段：
IF (SELECT COUNT(*) FROM posts WHERE user_id = :NEW.user_id AND updated_at > :NEW.updated_at - 60/86400) >= 5 THEN RAISE_APPLICATION_ERROR(-20001, 'exceeds update limit: 5 per minute'); END IF;
注意：:NEW 前面的冒号不能漏，这是 Oracle 触发器变量引用语法；子查询必须用括号包住，否则 PL/SQL 解析失败。
最后提醒一句：这个方案只适用于低频业务（比如后台管理、内部系统）。如果用户每秒改几十次，触发器会成为 DB CPU 瓶颈，而且无法跨实例同步计数 —— App 和 Web 同时改同一条记录，各自触发器只看到本地事务里的状态。真要高并发限频，得上 Redis + 应用层预检。
