数据库唯一约束是最可靠的重复日志拦截方式，通过 order_id 与 log_type 组合建唯一索引，可强制阻止重复插入并抛出 Integrity constraint violation 异常。
用数据库唯一约束强制拦截重复日志
订单日志重复最常见原因是业务逻辑里没做幂等校验，光靠代码判断容易漏。直接在数据库层面加约束最可靠——比如把 order_id 和 log_type（如 'paid'、'shipped'）组合设为唯一索引。
这样即使并发写入两条相同日志，第二条会触发 Integrity constraint violation 错误，而不是静默插入。你捕获这个异常后可以忽略或记录告警，但不会污染数据。
- 建索引示例：
ALTER TABLE order_logs ADD UNIQUE INDEX uk_order_type (order_id, log_type); - php 中捕获异常时注意区分错误类型，别把其他 sql 错误也当成重复处理
- 如果日志需要带时间戳或详情字段（如
remark），这些字段不能参与唯一索引，否则相同订单不同备注会被拦住
用 redis SETNX 做写前轻量级防重
适合高并发下单场景，在真正写库前先过一道缓存关卡。核心是用 SETNX 设置一个带过期时间的临时 key，比如 log_lock:order_12345:paid。
它比数据库锁快得多，且天然支持自动过期，避免死锁。但要注意：redis 不是强一致存储，网络分区或写入失败时可能漏判，所以它只能作为第一道过滤，不能替代数据库唯一约束。
立即学习“PHP免费学习笔记（深入）”；
- PHP 示例（使用 predis）：
$key = 'log_lock:order_' . $orderId . ':' . $logType; if ($redis->setnx($key, 1)) { $redis->expire($key, 30); // 30秒足够完成后续写库 // 继续写日志 } else { // 已存在，跳过或记录冲突 } - 不要用
SET ... NX EX一条命令代替SETNX + EXPIRE，老版本 Redis 不支持复合指令 - key 过期时间要略长于整个日志写入链路耗时（含事务、通知等），否则可能刚过期就又进来了
订单状态机驱动日志，而非事件触发
很多重复日志源于“支付成功”这类事件被多次投递（比如 MQ 重发、回调重复）。与其在每个事件入口做防重，不如把日志当作状态变更的副产品——只在订单状态从 pending → paid 等确定跃迁时才写。
状态变更本身必须是原子的（例如用 UPDATE orders SET status = 'paid' WHERE id = ? AND status = 'pending'），影响行数为 1 才算真正变更成功，这时再写日志才安全。
- 关键点：日志写入必须和状态更新放在同一个事务里，或者至少保证顺序和一致性
- 避免监听“支付回调成功”就写日志，而应查库确认当前订单是否真的从旧状态变到了新状态
- 如果用了消息队列，消费者端也要做幂等消费，比如记录已处理的
callback_id或out_trade_no
日志表主键别用自增 ID，改用业务组合键
自增主键对防重毫无帮助，反而掩盖问题。更合理的是把 id 设为联合主键或唯一键，比如 (order_id, log_type, created_at)，或者直接用雪花 ID / UUID 作主键并配合业务字段唯一索引。
这样做不只是为了防重，更重要的是让日志可追溯、可对账：同一笔订单的某类操作（如发货）理应只有一次有效记录，多出来就是异常。
- 不推荐用
created_at做唯一依据，毫秒级重复仍可能；优先选业务语义明确的字段组合 - 如果日志需要支持多次同类操作（如多次修改地址），那就得换思路：用版本号或序列号字段，比如
address_update_seq，并在写入前校验是否已存在更高序号 - 迁移旧表时注意历史数据去重，避免加约束失败
实际中最容易被忽略的是状态机与日志的耦合粒度——不是所有“事件”都该生成日志，只有那些导致订单领域状态真实跃迁的动作才值得落库。其余中间态、通知、校验失败等，记到调试日志或监控系统更合适。