MySQL积分系统需设计主表与流水表：主表用BIGINT存余额并加唯一索引，更新须原子校验；流水表记录每次变动并建联合索引；规则与过期策略结构化配置；并发下用事务+条件UPDATE保障一致性。
在 MySQL 中实现积分系统，核心是设计合理、可扩展、易维护的表结构，并配合业务逻辑保证数据一致性。重点不在“能不能存积分”，而在“如何安全、高效、可追溯地管理积分变动”。
积分主表：用户与积分余额的映射
这是积分系统的基石，记录每个用户的当前可用积分总额。
- 建议字段：
user_id（主键/外键）、balance（BIGINT，避免溢出）、freeze_balance（冻结积分，如待审核、活动锁定部分）、updated_at（最后更新时间） - 不要用 FLOAT 或 DECIMAL 存积分——积分是整数单位（如1分=1点），用 BIGINT 最稳妥
- 加个唯一索引
UNIQUE KEY(user_id)，避免重复插入 - 余额更新必须用
UPDATE ... SET balance = balance + ? WHERE user_id = ? AND balance + ? >= 0防超支，结合事务判断影响行数是否为1
积分流水表：每一次变动都必须可查、不可删
所有积分增减（签到、消费、退款、补偿）都必须记入此表，是审计、对账、排查问题的唯一依据。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 关键字段：
id（自增主键）、user_id、change_amount（正为+，负为−）、balance_after（操作后余额，便于快速核对）、type（TINYINT 枚举：1=签到，2=下单扣减，3=退款返还…）、ref_id（关联业务单号，如 order_no）、remark（简要说明，如“6月签到第3天”）、created_at - 务必建联合索引：
INDEX idx_user_time (user_id, created_at)，支持按用户查最近流水 - 不物理删除记录，用
is_deleted标记（但一般也不删，留痕优先）
积分规则与过期策略：用配置代替硬编码
积分不是全永久有效，不同来源积分可能有不同有效期（如活动赠送积分90天过期），需结构化支持。
- 可单设
points_rule表：定义规则类型（source_type）、有效期（days_valid）、是否可转赠、是否参与抽奖等 - 若需精确到每笔积分过期，可在流水表扩展
expire_at字段（适合精细化运营场景，如电商赠券式积分） - 定期任务（如每天凌晨）扫描
expire_at < NOW()且未冻结的积分，生成“过期扣减”流水，并更新用户主表余额
并发与一致性：避免超发、负扣、覆盖更新
高并发下（如秒杀送积分、批量签到），直接 UPDATE balance 容易出错。
- 所有积分变更必须走事务：先 INSERT 流水 → 再 UPDATE 主表 → 任一失败则回滚
- 主表更新推荐使用 SELECT FOR UPDATE 加行锁（尤其在读取当前余额再计算时），或更推荐：用带条件的 UPDATE 原子更新（如上文 balance + ? >= 0）
- 避免应用层“查-算-更”三步走；把计算逻辑尽量下沉到 SQL 层，减少竞态窗口
- 必要时引入 Redis 缓存当前余额（注意缓存与 DB 双写一致性，可用延时双删或订阅 binlog）
不复杂但容易忽略：上线前做压力测试，模拟千人同时签到或下单，验证流水不丢、余额不错、无死锁。表结构定稿后，给所有积分操作配上单元测试和对账脚本（比如每天比对“总流水sum(change_amount)”和“用户表sum(balance)”是否一致）。
