一张 user_subscriptions 表足够，初期只需记录谁订了什么、何时订、状态如何；关键字段包括 user_id、plan_id（可空）、status（枚举）、started_at、expires_at（null 表示长期有效）、created_at；避免布尔字段，加联合索引 idx_user_active_expire 优化查询。
用户订阅关系该用一张表还是多张表？
直接用一张 user_subscriptions 表就够了，不需要拆成「用户表」「订阅计划表」「订单表」三层结构——除非你已明确要支持退款、发票、多周期计费等 SaaS 级功能。初期最简模型只需记录「谁订了什么、何时订、状态如何」。
关键字段建议：user_id（外键）、plan_id（可为空，若需区分免费/付费档）、status（枚举：'active'/'canceled'/'expired'）、started_at、expires_at（用 DATETIME，别用 TIMESTAMP 避免时区隐式转换）、created_at。
- 不要用
is_active TINYINT(1)这类布尔字段——它无法表达「已取消但未过期」或「试用中」等中间状态 -
expires_at允许为NULL，代表长期有效（如终身会员），比硬编码一个远期时间（如 '9999-12-31'）更直观 - 如果未来要支持多订阅（同一用户同时订多个服务），必须加唯一约束：
UNIQUE KEY (user_id, plan_id)，否则靠应用层去重容易漏
怎么高效查「用户当前是否处于有效订阅中」？
别在每次请求时执行 SELECT COUNT(*) 或 SELECT status 再判断逻辑——这类查询会随数据量增长变慢，且容易因事务隔离级别导致误判（比如刚续费但事务未提交）。
推荐做法是：在读取用户权限前，用一条带条件的 SELECT 直接命中有效记录：
SELECT 1 FROM user_subscriptions WHERE user_id = ? AND status = 'active' AND expires_at > NOW();
这个语句必须配上联合索引：INDEX idx_user_active_expire (user_id, status, expires_at)。注意顺序不能调换——user_id 必须放最左，否则无法用于等值查询加速。
- 避免在
WHERE中对expires_at做函数操作，例如DATE(expires_at) > CURDATE()，会导致索引失效 - 如果业务允许几秒误差，可用
expires_at > DATE_SUB(NOW(), INTERVAL 5 SECOND)来规避刚过期瞬间的竞态，但别滥用 - 不建议用触发器或定时任务“提前更新 status 字段”——MySQL 的触发器不可靠，且状态变更应由业务逻辑驱动，而非数据库自动推演
订阅到期后数据怎么清理或归档？
不要用 DELETE FROM user_subscriptions WHERE expires_at 这种语句定期清理——它可能误删正在续费流程中的记录（比如支付回调延迟），而且删除操作会锁表、影响线上查询。
DESTOON B2B网站管理系统是一套完善的B2B(电子商务)行业门户解决方案。系统基于PHP+MySQL开发，采用B/S架构，模板与程序分离，源码开放。模型化的开发思路，可扩展或删除任何功能；创新的缓存技术与数据库设计，可负载千万级别数据容量及访问。
真实可行的做法只有两个：
- 把过期记录标记为
'expired'，而不是删除。保留原始数据至少 6 个月，便于对账和审计 - 如果磁盘压力确实大，用分表策略：按年或按季度建表（如
user_subscriptions_2024），再用RENAME TABLE+DROP TABLE下线旧表。注意迁移时停写窗口要控制在秒级，别用INSERT ... SELECT慢速拷贝
另外，expires_at 列一定要有索引（哪怕只是单列），否则 UPDATE ... WHERE expires_at 会全表扫描，高峰期可能拖垮主库。
为什么不能用 JSON 字段存订阅配置？
有人想把价格、周期、试用天数等动态参数塞进 config JSON 字段，图省事。这会让后续所有查询变脆弱：无法在 JSON 内字段上建索引、不能用 WHERE 直接过滤「月付用户」、备份恢复时 JSON 格式错误会导致整行丢失、ORM 映射也容易出错。
正确做法是把稳定维度拆成字段：billing_cycle ENUM('monthly', 'yearly')、trial_days TINYINT UNSIGNED、amount_cents INT NOT NULL（用整数存分，避免浮点精度问题）。
- 只有真正「每个订阅都不同、且从不用于查询条件」的元数据（比如某次优惠券 ID、来源渠道参数）才考虑放进 JSON
- MySQL 8.0+ 虽支持
JSON_CONTAINS，但它走不了索引，性能比普通字段差一个数量级 - 如果未来要对接 BI 工具做订阅转化分析，宽表结构比 JSON 更友好——不用先写 UDF 解析再聚合
设计时最容易被忽略的是时间精度与业务语义的错位：比如用 TIMESTAMP 存 expires_at，结果因服务器时区设置变化，导致一批用户提前 1 小时掉订阅。宁可全站统一用 UTC + DATETIME，也别依赖 MySQL 自动时区转换。
