MySQL不处理支付，仅存储订单状态；支付逻辑由应用层调用第三方网关完成，须经生成支付单、调用接口、接收校验通知、事务更新状态等步骤，且需幂等设计、状态机字段、乐观锁及补偿机制保障最终一致。
MySQL 本身不处理支付，它只负责可靠地存储和更新订单状态；真正的支付逻辑必须由应用层（如 Python/Java 服务）调用第三方支付网关（微信、支付宝）完成，MySQL 的角色是保证「支付结果」与「订单状态」最终一致。
为什么不能直接用 UPDATE orders SET status='paid' WHERE id=123 完成支付？
因为这会跳过支付网关校验，造成资金与状态严重不一致——用户没付款，订单却显示已支付。真实流程必须包含：生成支付单 → 调用支付接口 → 接收异步通知 → 校验签名与金额 → 更新订单状态。
-
UPDATE操作只能出现在「确认支付成功后」，且必须在事务中完成（例如同时扣减库存、记录支付流水） - 必须校验回调中的
out_trade_no（订单号）、total_amount（金额）、trade_status（交易状态）是否与数据库中原始订单完全匹配 - 重复通知很常见，
UPDATE前需先查当前状态，避免将'paid'错误覆盖为'paid'导致幂等失败
订单表设计必须支持支付状态机与并发安全
一个字段存状态远远不够。你需要至少三个关键字段：status（业务状态）、pay_status（支付网关返回状态）、version（乐观锁版本号）。
-
status取值建议为枚举：'created'、'paid'、'shipped'、'closed'，不直接暴露支付网关术语（如'TRADE_SUCCESS'） -
pay_status单独存微信/支付宝原始状态，便于对账和问题排查 - 更新时强制带上
WHERE id = ? AND status = 'created' AND version = ?，并用ROW_COUNT()判断是否更新成功，失败则重试或告警
如何防止「支付成功但订单未更新」的脏数据？
这是最危险的场景：用户付了钱，但数据库没改状态，导致无法发货、用户投诉。核心对策不是靠 MySQL 自身，而是靠「应用层补偿 + 数据库约束」双保险。
- 支付回调处理必须写入本地
pay_callback_log表（含原始参数、时间、处理结果），哪怕失败也要落盘 - 加一个定时任务（每分钟跑一次），扫描
orders表中status = 'created'且updated_at < NOW() - INTERVAL 5 MINUTE的订单，主动调用支付平台查询接口（query_order）核验真实状态 - 订单表主键必须是
id（BIGINT 自增或雪花ID），且out_trade_no字段加唯一索引 —— 防止同一笔支付重复插入多条订单
真正难的不是写 UPDATE 语句，而是把「支付结果不可靠」这个事实刻进每一行 SQL 和每个 if 判断里。只要漏掉一次签名校验、少一次幂等判断、忘加一个唯一索引，就可能在大促时批量产生资损订单。
