会员基础表必须包含user_id、status、mobile、email、password_hash、created_at、updated_at字段，其中user_id为主键，status标识状态，mobile建唯一索引，严禁明文存密码或混用软删除与业务状态。
会员基础表必须包含哪些字段
核心是区分「身份」和「状态」：身份靠 user_id（主键，推荐 BIGINT AUTO_INCREMENT 或 UUID），状态靠 status（TINYINT，如 0=禁用、1=正常、2=待验证）。别用 is_deleted 软删除代替状态字段——它和「封号」「冻结」「未激活」语义不同，混用会导致查询逻辑混乱。
必须有的字段包括：mobile（唯一索引，用于登录/找回）、email（可选唯一）、password_hash（不是 password！）、created_at、updated_at。别存明文密码，别用 md5()，用 bcrypt 或 MySQL 8.0+ 的 VALIDATE_PASSWORD 配合应用层哈希。
常见错误：把微信 openid、unionid 直接塞进主表。应该拆到 user_auths 关联表，支持同一用户多平台登录。
等级与权益要分开建表，别用 JSON 存规则
会员等级（如青铜、黄金、VIP）是有限且需频繁 JOIN 查询的维度，适合独立表 member_levels，含 level_id、name、min_points、max_points。用户当前等级存在 users.level_id，并加索引。
权益（如免运费、专属客服、折扣率）是组合式、可配置的，应建 member_privileges + user_privilege_grants 两张表。避免用 JSON 字段存权益列表——查「所有有免运费权限的用户」时无法走索引，也难做变更审计。
示例场景：运营临时给 VIP 用户加「生日双倍积分」权益，只需往 user_privilege_grants 插一条记录，不影响等级计算逻辑。
积分、余额、优惠券必须分库分表或至少分表
这三类数据写入高频、一致性要求高、且业务逻辑隔离性强。合并在 users 表里会导致锁表风险上升，特别是大促期间。
-
user_points：记录总积分、冻结积分、来源明细（用另一张point_logs记流水） -
user_balances：余额、可用余额、冻结余额，每次变更必须带version或用 SELECT FOR UPDATE 防超扣 -
coupons+user_coupons：优惠券模板和用户持有关系分离，过期、核销状态在user_coupons.status控制
别在 users 表里加 points、balance 字段——初期省事，半年后慢查询和事务冲突会集中爆发。
MySQL 8.0+ 推荐开启这些配置
不是功能开关，而是防坑底线：sql_mode 必须包含 STRICT_TRANS_TABLES，否则 INSERT INTO users (mobile) VALUES ('') 会静默转成 '0'，导致手机号丢失；explicit_defaults_for_timestamp=ON 避免 created_at 在某些 INSERT 场景下被意外设为 '0000-00-00 00:00:00'；innodb_strict_mode=ON 让外键、行格式异常立刻报错，不埋雷。
还有个容易被忽略的点：所有时间字段统一用 TIMESTAMP（自动时区转换）或统一用 DATETIME（无时区），别混用。尤其当应用部署在多个时区，又用 NOW() 和 SYSDATE() 混插时，数据对不上根本没法 debug。
