在线支付系统要求数据库事务原子性、可追溯、不可篡改，高并发下不丢单不重复不超卖；须显式事务、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 下可能读到旧值（幻读），二是没有锁住行，其他事务仍可读取同一行并发起竞争。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 必须用
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 压力巨大。
- 主键必须是自增
id（保证插入性能），但业务查询高频字段如order_id、out_trade_no、created_at必须建联合索引，例如：INDEX idx_order_time (order_id, created_at) - 按月分区（
PARTITION BY RANGE (TO_DAYS(created_at))），删除历史分区比DELETE快百倍，也避免大事务锁表 - 禁止在流水表里存冗余字段（如用户姓名、商品标题），只存必要 ID 和状态，详情查关联表 —— 否则单行变大，缓冲池命中率暴跌
如何让对账脚本不拖垮线上库
财务每天凌晨跑对账，SQL 类似 SELECT SUM(amount) FROM payment_transaction WHERE status = 'success' AND created_at BETWEEN ? AND ?。这种聚合扫表在大库上极易引发慢查询，进而阻塞写入线程。
- 绝不直接查原始流水表。应每日生成汇总快照表
daily_settlement_summary，含date、total_success_amount、total_refund_amount等字段，由写后触发器或异步任务维护 - 对账脚本只查快照表，哪怕某天快照异常，也能快速定位是结算逻辑错还是数据漏写
- 如果必须查原始流水，务必加上
FORCE INDEX指向覆盖索引，且用WHERE created_at >= ? AND created_at （注意是左闭右开），避免索引失效
CREATE TABLE daily_settlement_summary ( `date` DATE NOT NULL PRIMARY KEY, total_success_amount DECIMAL(18,2) DEFAULT 0, total_refund_amount DECIMAL(18,2) DEFAULT 0, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB;
最常被忽略的一点：支付系统里没有“小优化”。一个没加 FOR UPDATE 的余额更新，一次没设 TIMEOUT 的事务，一条没走索引的对账 SQL，都可能在流量高峰时变成雪崩起点。设计不是画 ER 图，而是预判每一行 SQL 在 5000 QPS 下锁多久、读多少页、写几个 binlog event。
