正确做法是只维护交易明细表,余额由明细实时或定时汇总得出;核心表为user_account(存身份状态)和account_transaction(存所有流水,含balance_after校验字段),通过事务+SELECT ... FOR UPDATE保证并发安全。

用 MySQL 实现余额系统,核心不是“存一个数字”,而是通过**事务 + 明细驱动余额**来保证数据一致性。直接更新余额字段(如 UPDATE account SET balance = balance - 100)在高并发下极易出错,也不可追溯。正确做法是:只维护交易明细表,余额由明细实时或定时汇总得出。
账户与交易明细表结构设计
至少需要两张表:用户账户基础信息表(可选)、交易流水表(必须)。不建议在账户表里存 balance 字段,除非做冗余缓存(需严格同步)。
-
user_account(用户账户主表,仅存身份和状态)
idBIGINT PK,user_idVARCHAR(32) UNIQUE NOT NULL, —— 业务侧用户标识(如手机号、open_id)statusTINYINT DEFAULT 1 —— 1:正常, 0:冻结 -
account_transaction(核心流水表,所有余额变动必须落此表)
idBIGINT PK AUTO_INCREMENT,user_idVARCHAR(32) NOT NULL,amountDECIMAL(18,2) NOT NULL, —— 正数为入账,负数为出账balance_afterDECIMAL(18,2) NOT NULL, —— 该笔完成后最新余额(关键!用于校验和快速查询)trade_noVARCHAR(64) UNIQUE NOT NULL, —— 外部订单号或内部生成的幂等号typeTINYINT NOT NULL, —— 1:充值, 2:消费, 3:退款, 4:转账入, 5:转账出等statusTINYINT DEFAULT 1, —— 1:成功, 0:失败/撤销, 2:处理中(慎用)created_atDATETIME DEFAULT CURRENT_TIMESTAMP,updated_atDATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
▶ 建议加联合索引:(user_id, created_at)和(trade_no)
关键操作:扣款与充值(事务安全写法)
每次资金变动,必须在一个事务中完成两件事:插入流水 + 校验余额是否充足(针对支出)。balance_after 字段值由程序计算后写入,不是数据库自增。
- 示例:用户 A 扣款 50 元(假设当前余额为 100)
BEGIN;SELECT balance_after FROM account_transaction WHERE user_id = 'A' ORDER BY created_at DESC LIMIT 1;→ 得到当前余额 100INSERT INTO account_transaction (user_id, amount, balance_after, trade_no, type) VALUES ('A', -50, 50, 'TX20240501001', 2);COMMIT;
⚠ 注意:SELECT 必须加FOR UPDATE锁住最新记录,防止并发重复扣款(如两个请求同时读到 100,都写入 50) - 更稳妥方式(推荐):用子查询+锁避免两次查询
INSERT INTO account_transaction (user_id, amount, balance_after, trade_no, type)SELECT 'A', -50, IFNULL(t.balance_after, 0) - 50, 'TX20240501001', 2FROM (SELECT balance_after FROM account_transaction WHERE user_id = 'A' ORDER BY created_at DESC LIMIT 1 FOR UPDATE) AS tWHERE IFNULL(t.balance_after, 0) >= 50;
▶ 若 WHERE 不成立,SQL 影响行为 0,事务可捕获并报“余额不足”
如何查余额?别 count,要聚合或取最新
有两种常用方式,按场景选择:
-
实时精确查:取该用户最新一笔成功的流水的
balance_afterSELECT balance_after FROM account_transaction WHERE user_id = 'A' AND status = 1 ORDER BY created_at DESC LIMIT 1;
✅ 快、准、无聚合开销;前提是每笔都正确写入 balance_after -
对账或修复用:从头累加所有成功流水
SELECT SUM(amount) FROM account_transaction WHERE user_id = 'A' AND status = 1;
⚠ 慢、不适合高频查询;但可用于日终核对或发现 balance_after 异常时定位问题
进阶建议:幂等、对账、冷热分离
-
幂等性:所有写操作必须带
trade_no并设唯一索引,防止重复提交导致多扣或多充 - 每日对账:凌晨跑批比对每个用户“最新 balance_after”和“SUM(amount)”是否一致,不一致则告警并人工介入
-
余额缓存(可选):如需毫秒级余额查询,可用 Redis 缓存
user_id → balance_after,但必须和 MySQL 流水严格绑定更新(如用 binlog 或事务后发消息) - 历史归档:流水表增长快,按月分表或转入历史库,保持主表轻量










