流水表必须带唯一业务单号trade_no并建唯一索引,用INSERT IGNORE或ON DUPLICATE KEY UPDATE防重;余额统一用BIGINT存最小单位,所有增减走原子UPDATE;对账分实时(查最近N条)与离线(每日全量SUM比对)两层;事务须同库同表,禁止跨库跨服务。流水表必须带唯一业务单号,不能只靠自增ID对账余额不准,90%出在流水重复或漏写。自增 id 只是插入顺序标识,不是业务凭证------同一笔充值可能因重试插入两次,而 id 不同但业务单号相同。流水表必须有 trade_no 字段(如 pay_202405211023456789),加唯一索引:UNIQUE KEY uk_trade_no (trade_no)写流水时用 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE 拦住重复单号,而不是靠应用层"查一遍再插"对账脚本比对时,只以 trade_no 为基准,完全忽略 id 和插入时间余额字段别存浮点数,用 BIGINT 存「分」或「最小积分单位」MySQL 的 FLOAT / DOUBLE 会丢失精度,比如 0.1 + 0.2 ≠ 0.3,积分清零、发放、扣减全乱套。哪怕你用 DECIMAL(12,2),也扛不住高并发下的读写竞争和四舍五入误差。统一用 BIGINT,单位是「1积分」,不带小数------用户看到的 12.5 积分,在库里存 1250(单位=0.01分)或直接 125(单位=0.1分),看业务粒度所有增减操作走 UPDATE user_point SET balance = balance + ? WHERE user_id = ? AND trade_no = ?,避免先查后更新余额校验脚本里,SUM(amount) 流水总和必须和 balance 完全相等,差1都不行------这是对账硬门槛对账不是"跑个SQL",得区分「实时核对」和「离线兜底」线上服务不能每笔都查流水总和来校验余额,太慢;但完全不校,出错发现就晚了。得拆成两层:轻量实时校验 + 异步全量对账。 MacsMind 电商AI超级智能客服
相关推荐
2603_965148117 小时前
如何解析JSON数据?API返回的商品信息处理教程ltl7 小时前
RocksDB 经典故障排查:L0、compaction 与 write stallxfhuangfu8 小时前
Oracle中建立到CDB和PDB的连接小小龙学IT9 小时前
DuckDB 深度实战:用 C++ 在进程内跑一个「分析型数据库」jufeng13079 小时前
【系列:手搓自主 AI Agent:Hermes 架构原理剖析 · 第 8 篇】NineData9 小时前
DTCC 2026 预告|NineData CEO& 创始人叶正盛:面向 AI Agent 的数据库 DevOps 与数据复制实践circuitsosk9 小时前
跨境电商智能化实战:AI如何赋能客服自动回复、广告智能投放与供应链预测J_bean10 小时前
MySQL 事务是否必须手动开启?J_bean10 小时前
MySQL InnoDB 如何检测死锁、判定死锁、处理死锁2601_9563198810 小时前
2026年零基础学量化:从看懂示例到写清条件和动作