DELETE FROM table WHERE ... 不够幂等，因其重复执行返回“影响0行”，无法区分“本就无数据可删”和“已删完再执行”，导致归档脚本在重试或误点时状态不可控；幂等性要求多次执行结果完全一致，而DELETE不反馈是否真实删除，掩盖关键事实。
为什么直接写 DELETE FROM table WHERE ... 不够幂等
因为重复执行会报“影响 0 行”，看似无害，但掩盖了关键状态：你无法区分“本就没人要删”和“刚删完又跑一遍”。归档脚本常被调度系统重试或人工误点，必须让多次执行结果完全一致——要么删干净且不再删，要么不删就不删。
核心矛盾在于：SQL 的 DELETE 本身不返回“本次是否真删了数据”，而幂等性依赖这个事实判断。
- 常见错误现象：
DELETE FROM orders WHERE status = 'archived' AND created_at 被执行两次，第二次返回0 rows affected，但日志里看不出是“已清空”还是“条件写错了” - 根本原因：没锁定操作边界。条件中用了非唯一字段（如
status、created_at），数据可能在两次执行间被插入/更新，导致行为不可预测 - 正确思路：用唯一标识锚定一批记录，并确保该锚点在脚本生命周期内不变（比如用归档批次号、或带时间戳的确定范围）
用 DELETE ... LIMIT + ROW_COUNT() 实现可验证的幂等删除
MySQL 和部分兼容引擎支持 ROW_COUNT() 获取上一条语句实际影响行数，这是判断“是否真删”的最轻量方式。配合 LIMIT 可避免单次删太多卡住事务。
示例（MySQL）：
SET @batch_id = 'archive_2024q2_v1'; DELETE FROM orders WHERE batch_id = @batch_id LIMIT 10000; SELECT ROW_COUNT() AS deleted_count;
说明：
-
batch_id是归档前为这批数据批量打上的唯一标记（不是靠时间范围猜），保证条件绝对稳定 -
LIMIT防止锁表太久；若需删更多，脚本外循环执行，每次检查ROW_COUNT()是否为 0 再退出 - 不依赖
created_at等易变字段，避免因时钟回拨、数据延迟入库导致漏删或误删 - 注意：
ROW_COUNT()在存储过程中才可靠；纯客户端执行时，某些驱动（如旧版 JDBC）可能取不到，得用executeUpdate()返回值
PostgreSQL 怎么做？用 RETURNING 捕获删除凭证
PostgreSQL 没有全局 ROW_COUNT()，但 RETURNING 子句能直接拿到被删行的主键或哈希值，既验证又留痕。
示例：
WITH deleted AS (
DELETE FROM orders
WHERE batch_id = 'archive_2024q2_v1'
RETURNING id, md5(concat(id, updated_at)::text) AS row_hash
)
SELECT count(*) as deleted_count,
md5(string_agg(row_hash, ',')) as batch_signature
FROM deleted;
好处：
- 返回
deleted_count直接告诉你删了几行 -
batch_signature是这批删除的指纹，可存入日志或控制表，下次执行前先查这个签名是否存在，存在则跳过 - 比查表再删更安全：避免“查到 1000 行 → 中断 → 再次查到同样 1000 行 → 重复删”这种竞态
- 注意：
RETURNING在事务中才生效；如果脚本分多事务执行，需确保每个事务的batch_id唯一，否则签名会冲突
归档脚本里最容易被忽略的三个细节
幂等不只是 SQL 写对，整个脚本链路都要收敛：
- 归档前必须给目标数据打标（如
UPDATE ... SET batch_id = 'xxx' WHERE ...），且该语句本身也要幂等（用WHERE batch_id IS NULL限定） - 清理后建议写控制表（如
archive_log(batch_id, table_name, deleted_count, started_at, finished_at)），否则重试时无法判断“上次删到哪了” - 别在
WHERE条件里混用函数，比如WHERE DATE(created_at) —— 会导致索引失效，且不同执行时刻函数结果可能因时区/表达式求值顺序微变
真正难的不是写一条删语句，而是让整条归档流水线每一步都可重入、可追溯、可对账。
