postgresql delete不支持limit，触发器无法可靠限制删除行数；应使用cte子查询（如with to_delete as (...) delete from ... where ctid in (...)）配合order by和索引实现可控限删。
PostgreSQL 的 DELETE 不支持 LIMIT，触发器不能直接限删行数
PostgreSQL 原生 DELETE 语句不接受 LIMIT 子句，强行加上会报错 ERROR: syntax error at or near "LIMIT"。更关键的是：**触发器本身不是限制删除行数的合适工具**——它在数据变更事件发生时响应，而“删多少行”这个控制点必须在语句执行前就定死，不能靠触发器事后拦截或截断。
为什么不能在 BEFORE DELETE 触发器里统计并拒绝超量删除？
BEFORE DELETE 触发器是按行触发（默认行级），每删一行就进一次，但你无法在触发器里知道“这次 DELETE 语句总共打算删多少行”。常见误区是想在触发器里查 COUNT(*) 或用 tg_argv 获取参数，实际都不可行：
-
COUNT(*)在触发器中查的是当前已提交状态，无法反映本次语句将影响的行集（MVCC 隔离下甚至可能看到旧快照） - PostgreSQL 触发器函数不接收 SQL 语句的原始 LIMIT 值，
tg_argv是手动传参，不是自动注入的 - 即使你在触发器里
RAISE EXCEPTION，也只能中断当前这一行的删除，其余行仍会继续删（除非显式定义为语句级 + 提前退出，但语句级触发器拿不到单行数据，校验逻辑又落空）
真正可行的限删方案：CTE + 主键/索引驱动的子查询
生产环境应放弃“用触发器限删”的想法，改用显式、可控、可审计的 CTE 写法。核心是把“选哪几行”和“删这几行”拆成原子两步，且依赖索引避免全表扫描：
WITH to_delete AS ( SELECT ctid FROM logs WHERE status = 'archived' ORDER BY created_at ASC LIMIT 1000 ) DELETE FROM logs WHERE ctid IN (SELECT ctid FROM to_delete);
说明：
- 用
ctid而非主键，是因为它物理定位快，且无需额外索引；若表有带索引的时间字段（如created_at），优先用该字段排序+主键过滤 -
ORDER BY必须存在，否则LIMIT结果无序，删哪几行不可控 - 若要防并发干扰（比如两个脚本同时跑，都删了同一批老数据），可在 CTE 中加
FOR UPDATE SKIP LOCKED（需 PostgreSQL ≥ 9.5） - 此写法可安全用于事务中，失败时整批回滚
如果业务真需要“每次最多删 N 行”的守门逻辑，得移到应用层或存储过程
数据库层没有“语句级限流”机制，硬要在 DB 侧兜底，只能靠存储过程封装检查 + 删除两步，并用显式锁规避竞态：
- 先
SELECT COUNT(*)满足条件的行 → 判断是否 ≤ N - 若超限，只取
ORDER BY ... LIMIT N的 ID 列表 - 用这些 ID 执行
DELETE，并确保整个过程在同一个事务 +SELECT ... FOR UPDATE锁住目标行 - 注意：这种做法会放大锁持有时间，高并发下易成瓶颈，不如把限删逻辑交给应用控制批次大小
触发器在这里既不必要，也不可靠——它解决不了“语句意图”和“执行结果”之间的鸿沟，反而增加调试复杂度和隐性性能损耗。
