在线支付系统要求数据库事务原子性、可追溯、不可篡改，高并发下不丢单不重复不超卖；须显式事务、READ COMMITTED及以上隔离级、DECIMAL存金额、SELECT … FOR UPDATE防超扣、流水表分区+覆盖索引+快照表对账。
在线支付系统对数据库的要求不是“能存数据”，而是“每笔交易都必须原子、可追溯、不可篡改，且在高并发下不丢单、不重复、不超卖”。MySQL 能做，但默认配置和随意建表会立刻出问题。
为什么不能直接用 INSERT INTO orders 就完事
支付场景下，一个「下单→扣款→更新状态」流程涉及多个表联动（订单、账户余额、流水、风控日志），而 MySQL 的默认 autocommit=1 会让每个语句自动提交——这意味着一旦中间步骤失败（比如余额校验通过后，写流水时磁盘满），前面已执行的更新无法回滚，造成状态不一致。
- 必须显式开启事务：
BEGIN→ 所有操作 →COMMIT或ROLLBACK - 隔离级别至少设为
READ COMMITTED（避免不可重复读影响对账），生产环境推荐REPEATABLE READ，但要配合SELECT ... FOR UPDATE做行锁 - 所有涉及金额的字段，类型必须是
DECIMAL(18,2)，绝不用FLOAT或DOUBLE—— 否则 0.1 + 0.2 ≠ 0.3 是真实发生的线上事故
account_balance 表怎么防超扣与幻读
用户付款时要检查余额是否足够，并立即锁定该行防止并发扣减。单纯 UPDATE account_balance SET balance = balance - ? WHERE user_id = ? AND balance >= ? 看似安全，实则存在两个漏洞：一是 WHERE 条件中的 balance >= ? 在 MVCC 下可能读到旧值（幻读），二是没有锁住行，其他事务仍可读取同一行并发起竞争。
- 必须用
SELECT balance FROM account_balance WHERE user_id = ? FOR UPDATE先加行锁，再判断余额，再UPDATE - 该语句必须在事务内执行，且该事务不能持有锁过久（例如不能在锁住账户后去调第三方支付接口）
- 表上必须有
user_id的唯一索引，否则FOR UPDATE会升级为间隙锁甚至表锁
支付流水表 payment_transaction 的索引与分区策略
流水表是写多读少、按时间线性增长的典型，单表超千万行后，SELECT * FROM payment_transaction WHERE order_id = ? 即使有索引也会变慢，因为 B+ 树深度增加；更麻烦的是对账任务常需扫描某天全量流水，全表扫描 I/O 压力巨大。
