WHERE条件必须包含状态校验，不能仅靠主键更新；正确做法是使用原子条件如WHERE id = 123 AND status != 'shipped'，并用ROW_COUNT()判断是否真正变更，确保幂等性。
WHERE 条件必须包含状态校验，不能只靠主键
直接用 WHERE id = ? 更新是常见错误。它能防止语法报错，但无法阻止重复执行导致的业务逻辑错乱。比如订单发货脚本跑两次，第二次仍会把 status 改成 'shipped'，哪怕它已经是 shipped 状态。
真正起作用的是带状态判断的原子条件：
UPDATE order SET status = 'shipped', updated_at = NOW() WHERE id = 123 AND status != 'shipped'- 若需限定只能从某个状态流转过来：
WHERE id = 123 AND status = 'confirmed' - 若要记录首次变更时间且避免覆盖：
shipped_at = COALESCE(shipped_at, NOW())，但注意NOW()在 MySQL 中是语句开始时间，高并发下可能不精确
存储过程内部别用 SELECT + UPDATE 做判断
在过程里写 SELECT status INTO @cur_status FROM order WHERE id = ? 再 IF @cur_status != 'shipped' THEN UPDATE ...，看似清晰，实则埋雷。
问题出在非原子性：两个并发调用可能同时读到 'confirmed'，然后都执行更新。除非加 SELECT ... FOR UPDATE，但这会把锁暴露给过程调用上下文，而运维脚本或定时任务往往没事务包装，锁可能被忽略或提前释放。
更糟的是，某些数据库驱动（如部分 JDBC 配置）或 ETL 工具（如 Informatica 的 pre SQL）根本不支持显式锁语句，执行时静默失败。
DDL 操作也要幂等，但不能靠 TRY/CATCH 跳过错误
MySQL 不支持 ALTER TABLE ADD COLUMN IF NOT EXISTS（直到 8.0.23 才部分支持），所以直接执行 ALTER TABLE t ADD COLUMN x INT 第二次就会报错 ERROR 1060 (42S21): Duplicate column name 'x'。
靠捕获异常再忽略，不可靠，因为不同版本、不同引擎报错码和消息格式可能不同。稳妥做法是前置检查：
- 查
information_schema.COLUMNS：SELECT COUNT(*) FROM information_schema.COLUMNS WHERE table_name = 't' AND column_name = 'x' AND table_schema = DATABASE() - 在存储过程中用
IF (SELECT ...) = 0 THEN ALTER ... END IF; - PostgreSQL 用户可直接用
ALTER TABLE t ADD COLUMN IF NOT EXISTS x INT，但注意该语法不适用于索引或约束
返回影响行数比抛异常更能说明幂等是否生效
执行完 UPDATE 后，用 ROW_COUNT() 检查实际改了几行，比依赖成功/失败状态更真实。值为 0 表示本次执行未改变数据——这正是幂等的核心信号。
可在存储过程中这样封装：
UPDATE order SET status = 'shipped' WHERE id = in_id AND status != 'shipped'; IF ROW_COUNT() = 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Order already shipped or not found'; END IF;
但注意：如果业务允许“无操作即成功”，就别抛错，而是让调用方根据 ROW_COUNT() 自行判断；强行统一抛异常反而破坏了幂等的本意——它不是防重，而是容重。
最容易被忽略的一点：幂等性不是靠“阻止执行”来实现的，而是靠“执行了也白执行”来保障。所有检查逻辑必须落在数据库单条语句的原子边界内，一旦跨语句、跨事务、跨网络，就不再是真正的幂等。
