ROW_NUMBER() 不能直接实现幂等性，仅能辅助生成序号用于日志追溯、批量去重或疑似重复识别；真正幂等性依赖外部唯一键（如request_id），需结合唯一索引、应用层校验及稳定游标机制共同保障。
ROW_NUMBER() 不能直接解决幂等性，但能辅助生成唯一请求标识
很多人误以为 ROW_NUMBER() 可以直接用于判断重复请求，其实它只是窗口函数，不带业务语义。真正的幂等性检查必须依赖外部唯一键（比如客户端传的 request_id），ROW_NUMBER() 只能在特定场景下帮你在**无可靠外部 ID 时临时构造可追溯的序号**——例如日志表中按时间+参数打序，便于人工排查或触发补偿逻辑。
在 INSERT 场景中用 ROW_NUMBER() + 唯一约束防重入
如果你的 API 入口会批量写入请求记录，且上游无法保证 request_id 唯一，可以靠数据库层兜底：先用 ROW_NUMBER() 对同一批次数据按关键字段（如 user_id, order_no, timestamp）排序去重，再结合唯一索引拦截重复。
- 建唯一索引：
CREATE UNIQUE INDEX idx_req_uniq ON api_log (user_id, order_no, DATE(timestamp)) - 插入前加序号标记：
INSERT INTO api_log (user_id, order_no, timestamp, seq_no) SELECT user_id, order_no, timestamp, ROW_NUMBER() OVER (PARTITION BY user_id, order_no, DATE(timestamp) ORDER BY timestamp) as seq_no FROM staging_requests;
- 注意：如果
staging_requests里已有重复，ROW_NUMBER()会给它们分配不同序号，但后续唯一索引会报duplicate key value violates unique constraint，需捕获该错误并跳过或告警
用 ROW_NUMBER() 识别“疑似重复”的请求批次
当客户端未传 request_id，又需要快速识别同一用户短时间内相似请求时，可用 ROW_NUMBER() 搭配时间窗口和参数哈希做轻量级聚类。
- 示例：查出 5 分钟内相同
user_id和api_path的请求中，第 2 次及以后的调用SELECT * FROM ( SELECT *, ROW_NUMBER() OVER ( PARTITION BY user_id, api_path, MD5(params) ORDER BY created_at ) AS rn FROM api_call_log WHERE created_at > NOW() - INTERVAL '5 minutes' ) t WHERE t.rn > 1; -
MD5(params)是简化做法，实际建议用更稳定的序列化方式（如 JSONB 哈希），否则空格、字段顺序差异会导致哈希不一致 - 这个查询不能替代幂等控制，只适合监控或告警；真要拦截，得在应用层提前查
SELECT 1 FROM api_log WHERE request_id = ?
ROW_NUMBER() 在分页游标中的误用风险
有人想用 ROW_NUMBER() 生成游标值（如把序号当 cursor 返回给前端），再下次请求时用 WHERE rn > ? 实现“幂等翻页”。这非常危险：
- 并发写入时，两次查询看到的
ROW_NUMBER()结果可能不同（因为排序依据字段被更新） - 一旦中间有 DELETE 或 UPDATE，序号会漂移，导致漏数据或重复
- 正确做法是用稳定字段（如
id或created_at + id）做游标，例如：WHERE created_at > ? OR (created_at = ? AND id > ?)
真正影响幂等性的，永远是请求标识的生成、传递与校验闭环，ROW_NUMBER() 只是辅助工具，别让它承担它扛不动的责任。
