防重表必须用业务唯一ID作主键或唯一索引，如order_no、trade_no或message_id；禁用自增ID；需与业务操作同事务；用INSERT IGNORE/ON CONFLICT原子写入；定期清理过期数据。
防重表字段设计必须用业务唯一ID，不能只靠自增主键
防重表不是用来“记流水”的，而是用来“判重复”的。如果只用数据库自增 id 当主键，那根本拦不住重复消息——每条消息插入都会成功，完全失去去重意义。
正确做法是把业务天然唯一的标识作为主键或唯一索引，比如订单号 order_no、支付流水号 trade_no、或生产端生成的 message_id。这个字段必须由上游确定、全局唯一、不可篡改。
- 推荐建表语句：
CREATE TABLE t_dedup (msg_id VARCHAR(64) PRIMARY KEY, created_at DATETIME DEFAULT NOW()) - 避免用
INT AUTO_INCREMENT做去重依据——它不携带业务语义，也无法跨服务对齐 - 如果业务没现成唯一ID，必须由生产者生成 UUID 或 Snowflake ID 并透传，不能由消费者临时拼接
INSERT IGNORE 和 ON CONFLICT 是最稳的写入方式
用 SELECT + INSERT 两步走，在并发场景下大概率出问题：两个线程同时查不到记录，然后都插入成功。这不是理论风险，是压测必现的 bug。
真正可靠的写法，是靠数据库原子性完成“存在即失败”判断。MySQL 用 INSERT IGNORE，PostgreSQL 用 ON CONFLICT DO NOTHING，它们都在单条 SQL 内完成校验与写入，不会被并发打断。
立即学习“Python免费学习笔记（深入）”；
- Python 示例（SQLAlchemy）：
session.execute(text("INSERT IGNORE INTO t_dedup (msg_id) VALUES (:msg_id)"), {"msg_id": msg_id}) - 执行后检查
rowcount：等于 0 表示已存在，直接跳过后续业务逻辑；大于 0 才继续处理 - 别用
try...except IntegrityError捕获唯一键冲突——它属于异常流，性能差且掩盖真实意图
防重表必须和业务操作在同一个事务里
很多人把“插防重表”和“更新订单状态”分成两个事务，以为只要先插成功就能防重。错。一旦中间发生崩溃或网络断开，就会留下防重记录但业务没执行，下次消息来反而被跳过，导致漏处理。
必须确保：防重记录写入和业务变更要么全成功，要么全回滚。否则幂等就变成了“半截幂等”，比不做还危险。
- 使用同一 DB 连接、同一
session，所有操作包裹在session.begin()和session.commit()中 - 不要在防重表用 Redis 替代数据库——Redis 没有事务一致性，无法保证和 MySQL 业务表强一致
- 如果业务本身跨库（如订单库 + 库存库），防重表必须和核心业务表同库，否则无法加分布式事务
别忘了清理老数据，否则防重表会越涨越大
防重表不是日志表，不需要永久保留。消息处理完一段时间后（比如 7 天），对应记录就没用了。不清理，轻则磁盘爆满，重则 INSERT IGNORE 变慢——索引膨胀会影响所有写入性能。
- 加定时任务（如 Celery beat 或系统 cron），每天凌晨执行：
DELETE FROM t_dedup WHERE created_at - 清理 SQL 必须带
WHERE条件，并确保created_at字段有索引，否则会锁表 - 上线前先估算数据量：按每秒 1000 条消息算，7 天就是 6 亿行，没清理机制根本扛不住
