首次承接自由职业项目，用户数据库schema设计纠结：选单表还是分表？

核心建议采用 主表存高频核心字段 + 扩展表存低频迭代字段 的折中方案，既能避免单表迭代改表的麻烦，也能规避多表联查的性能损耗，完全匹配中小项目的迭代需求。

1. 两种极端方案的弊端 #

• 纯单表方案：如果项目后续用户量涨到百万级以上，新增字段需要锁表，确实会影响线上业务；且大量低频字段冗余存储，每次查询核心信息都会产生不必要的IO开销。
• 纯多表拆分方案：中等使用频率的字段每次调用都要联表，不仅增加代码复杂度，对于初期用户量不大的项目来说，联查性能损耗远大于字段拆分带来的收益，属于过度设计。

2. 推荐的折中设计 #

核心用户主表 users #

仅存放当前已经明确的、业务逻辑高频调用的稳定字段：
id（自增主键，必填）、name、password、email、phone、is_active、email_verified、phone_verified、is_admin、is_worker、is_verified、has_payment、last_login、created_at

这些字段都是用户生命周期内固定存在的，几乎不会被删除，改动概率极低，单表存储查询性能最高，业务代码不需要做联表处理。
注意给email、phone字段加唯一索引，避免重复注册。

用户扩展表 user_extensions #

用于存放未来新增的低频、临时、迭代频率高的字段，采用K-V结构设计：
id、user_id（关联主表用户ID）、key（字段类型，比如token、otp、otp_limit）、value（字段值）、expired_at（可选，用于存储临时生效的字段）

后续新增扩展字段完全不需要修改表结构，直接新增对应的key类型即可，完美解决迭代改表繁琐的问题。只有调用对应功能时才查询该表，不会影响主表的常规查询性能。
注意给user_id字段加普通索引，关联查询效率更高。

3. 特殊场景适配 #

• 如果项目初期预估用户量不超过10万，可直接先上纯单表方案，优先快速推进业务上线，等后续用户量上涨、扩展字段增多后再做数据迁移即可，不用提前做冗余设计。
• 如果使用PostgreSQL等支持JSON类型的数据库，可直接在主表新增extra JSON字段存放扩展内容，不需要单独做扩展表，开发更便捷，性能也完全满足中小项目需求。

内容的提问来源于stack exchange，提问作者Jenifer_009