数据库唯一约束是最可靠的重复日志拦截方式，通过 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，并在写入前校验是否已存在更高序号
• 迁移旧表时注意历史数据去重，避免加约束失败