MySQL中代币余额统计：用计算还是新增表存储？

两种方案的核心对比 #

方案1：基于现有两张明细表实时计算余额 #

• 优势：
  • 数据绝对一致：余额完全由交易明细推导，不会出现余额和流水对不上的情况，对账、排查问题时更省心。
  • 维护成本低：不需要额外新增表，减少数据库结构复杂度，备份、迁移时也少一张表需要处理。
  • 适配简单业务：如果只是基础的购买/消费逻辑，给交易表加个user_id索引后，SUM(购买量) - SUM(消费量)的查询速度完全够用，哪怕单用户有几千条记录。
• 劣势：
  • 高并发/大数据量下性能受限：如果单用户交易记录过万，或者平台有大量用户同时查询余额，频繁的聚合计算会占用数据库CPU资源，拖慢响应速度。
  • 复杂业务扩展麻烦：如果后续要加代币冻结、过期、分层额度这类逻辑，聚合计算的SQL会变得非常复杂，甚至难以维护。

方案2：新增余额表，实时更新余额 #

• 优势：
  • 查询性能拉满：直接读取余额字段，毫秒级响应，完美适配高并发场景下的余额查询需求。
  • 业务扩展性强：可以在余额表中轻松新增可用余额、冻结余额、过期时间等字段，支撑复杂的代币规则。
• 劣势：
  • 一致性风险高：必须用事务保证“明细写入+余额更新”的原子性，一旦事务失败或者代码逻辑有漏洞，就会出现余额和流水不符的情况，排查和修复成本极高。
  • 额外维护成本：多一张表意味着多一份备份、监控、迁移的工作，还要定期做对账校验（比如每天跑脚本对比明细计算的余额和余额表数值），避免数据偏差积累。

决策建议 #

• 优先选实时计算的场景：用户量小、交易频率低，或者对账准确性是第一优先级的平台。只要给交易表的user_id字段加好索引，日常查询的性能完全能满足需求。
• 考虑新增余额表的场景：平台有高并发余额查询需求，或者单用户交易记录量级很大（上万条以上），或者需要扩展复杂的代币规则。但一定要做好这两点：
  1. 所有涉及余额变动的操作（购买、消费、冻结、解冻等）必须放在同一个数据库事务里执行，保证明细和余额的更新要么同时成功，要么同时失败。
  2. 定期执行对账脚本，自动校验所有用户的明细计算余额和余额表数值，发现不一致时自动修正（或者触发告警人工处理）。

内容的提问来源于stack exchange，提问作者Alex Hofer