用户表应按业务阶段分层设计，初期用最小必要字段保上线，中后期再依安全、审计、扩展需求逐步添加；主键优先选bigint unsigned（用户量预期超2000万）或int unsigned（否则更省空间），避免盲目堆字段拖慢查询、增加索引开销及一致性风险。
直接说结论：用户表不是越全越好，而是要按业务阶段分层设计——初期用最小必要字段保上线，中后期再按安全、审计、扩展需求逐步加字段；盲目堆字段会拖慢查询、增加索引开销，还容易埋下数据一致性隐患。
主键选 INT 还是 BIGINT
别凭感觉选。如果用户量预期会超 2000 万（比如 SaaS 平台、社交 App），直接用 BIGINT UNSIGNED；否则 INT UNSIGNED 更省空间、索引更紧凑。MySQL 的 AUTO_INCREMENT 在 INT 下最大值是 2147483647，看似很大，但高并发写入场景下可能几年就耗尽。
- 电商订单号、用户 ID 等业务主键，建议用雪花 ID 或 UUID（存为
CHAR(36)或BINARY(16)），避免自增暴露业务规模 - 如果用自增，必须搭配
NOT NULL和PRIMARY KEY，否则EXPLAIN会显示Using filesort -
SMALLINT/TINYINT不适合用户 ID，哪怕当前只有几百人——它限制了未来水平拆分的可能
VARCHAR 长度不能拍脑袋定
字段长度直接影响行大小、缓冲池利用率和排序性能。比如 email 字段，RFC 标准上限是 254 字符，但实际系统里极少有超 100 字符的邮箱；设成 VARCHAR(255) 看似保险，却会让 InnoDB 每行多预留 1–2 字节长度头，百万级表就是 MB 级浪费。
-
username：中文名+英文名混合场景，VARCHAR(50)足够（UTF8MB4 下最多 150 字节） -
password：存的是哈希值（如 bcrypt 输出固定 60 字符），VARCHAR(255)是安全冗余，VARCHAR(100)够用但无扩展余地 -
phone：国际号码最长 15 位（含国家码），VARCHAR(20)足够，别用INT——前导零、+ 号、分隔符都会丢 - 所有
VARCHAR字段必须加NOT NULL，除非业务明确允许空值；NULL 列在二级索引中不存储，会导致COUNT()统计不准
时间字段用 DATETIME 还是 TIMESTAMP
二者语义不同：TIMESTAMP 存的是 UTC 时间戳（4 字节），读写时自动转本地时区；DATETIME 存的是字面值（5 字节），不涉及时区转换。生产环境强烈推荐统一用 DATETIME，尤其当应用部署在多时区或容器化环境时。
-
created_at DATETIME DEFAULT CURRENT_TIMESTAMP—— 记录插入时刻，不随更新变 -
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP—— 注意 MySQL 8.0+ 才支持两个字段都用CURRENT_TIMESTAMP，5.7 只能一个用DEFAULT，另一个靠触发器或应用层维护 - 别用
INT存 Unix 时间戳：失去日期函数（DATE_ADD、YEAR()）能力，且无法被 MySQL 优化器用于范围扫描
敏感字段和权限字段怎么处理
身份证、手机号、邮箱这些字段不是“存得下就行”，而要从存储、访问、脱敏三层面设计。比如 credential_no（身份证号）必须加密存储（AES-256），且不能建索引——否则密文索引等于明文泄露。
- 角色字段优先用
TINYINT UNSIGNED+ 注释说明（如0=guest, 1=user, 10=admin, 11=audit），比ENUM更易扩展、迁移 - 状态字段（
status）务必加检查约束：CHECK (status IN (0,1,2))，避免脏数据污染业务逻辑 - 邮箱、手机号等唯一性校验，必须建
UNIQUE索引，但要注意 NULL 值不参与唯一约束——所以字段定义必须带NOT NULL - 密码重置令牌、OAuth token 等临时凭证，单独建表（如
user_token），不要塞进主表；过期机制用expires_at DATETIME+ 应用层清理，别依赖 MySQL 事件调度器
真正难的不是字段列多少，而是每个字段背后的生命周期管理：谁写、谁读、是否可为空、是否参与索引、是否要审计变更——这些决定了表能不能撑住三年后的日活千万。
