VIP 与等级 · 数据与表结构

按业务域拆表

不要把所有表堆在一个库里。VIP 与等级至少要分清：用户域、资金域、牌局域、运营域。资金域单独库或单独实例，便于审计与恢复。

关键表设计要点

• 用户表：账号、设备、来源渠道分离
• 钱包表：余额与冻结分开，所有变动走流水
• 订单表：唯一订单号 + 状态机 + 幂等键
• 牌局表：过程事件流，别只存结果

索引与性能

与钱包、房间服务联动。高频查询字段必须建索引；大字段（牌局明细、日志）单独表并做归档。

常见反模式

1. 权益写死
2. 降级逻辑缺失
3. 跨游戏不通用

迁移与归档

给每张大表定归档策略：超过 N 天的明细转冷存储。没有归档，半年后查询会明显变慢。

三张表的字段怎么留余量

用户表留来源渠道与设备指纹，方便后面做归因；钱包流水留业务类型与关联单号，方便对账；牌局表留完整事件流与版本号，规则改了也能回放旧局。

留余量的原则是「加字段便宜，改结构很贵」。不确定要不要的字段，先加上、先不写。

性能上的两条经验

一是别在流水表上做大范围统计，用汇总表；二是别用 LIKE '%x%' 查业务数据，那是全表扫。数据量上来后，这两条能省掉大部分慢查询。

要点回顾

• 先确认交付边界：服务端源码、数据库脚本、后台是否齐全
• 先用最小环境跑通「登录-开局-结算-提现」主链路
• 上线前准备备份与回滚，上线后建立性能与错误基线
• VIP 与等级的长期成本在运维与运营，不在首次采购

以上是针对VIP 与等级的实操梳理。不同团队的基础不同，落地时按自己的进度取舍，不必一次全做。

常见误区

在VIP 与等级上，最常见的三个误区是：把功能数量当成能力、把演示当成交付、把上线当成结束。数据与表结构阶段真正要确认的是可维护性——半年后还有没有人能改得动这套代码。

可维护性的判断方法很朴素：让开发把「有付费分层」这一处逻辑讲一遍，讲不清就说明代码和文档都没跟上。

一句话小结

VIP 与等级的数据与表结构，本质是把不确定的部分提前确认：交付边界、技术栈（与钱包、房间服务联动）、以及最容易翻车的 有付费分层。这三点确认清楚，剩下的都是执行问题。