用户表设计需兼顾查询性能与扩展性：username/email需UNIQUE约束及B-tree索引；密码哈希用VARCHAR(255)；status用TINYINT；created_at等常用查询字段须建索引；登录查询应建(username, status)联合索引；权限管理须用RBAC三表模型；分页宜用游标替代OFFSET；千万级数据慎用COUNT(*)。
用户表设计必须支持快速查询与扩展
用户管理系统中，users 表是核心，但直接用 id + username + password_hash 三字段起步，很快会卡在登录、搜索、权限关联等环节。关键不是字段多，而是索引和数据类型是否匹配真实访问模式。
-
username和email必须加UNIQUE约束，且分别建 B-tree 索引；若支持邮箱登录，email索引不可省略 - 避免用
TEXT存密码哈希——VARCHAR(255)足够（bcrypt 输出固定长度，Argon2 一般 ≤ 128 字符） - 状态字段如
status建议用TINYINT（0=禁用, 1=启用, 2=待验证），别用字符串枚举，否则无法高效走索引 - 若需按注册时间分页查新用户，
created_at必须有索引；若常查“最近7天活跃用户”，可考虑生成列 + 函数索引（MySQL 8.0.13+）：ALTER TABLE users ADD COLUMN created_date DATE AS (DATE(created_at)) STORED;
CREATE INDEX idx_created_date ON users(created_date);
登录认证时避免全表扫描和慢查询
典型错误是写 SELECT * FROM users WHERE username = ? AND status = 1 却没给 (username, status) 建联合索引。MySQL 无法只靠 username 索引过滤 status，尤其当大量用户被禁用时，性能断崖下跌。
- 联合索引顺序很重要：高频等值查询字段放前面，
username比status更具区分度，所以建INDEX idx_username_status (username, status) - 不要在
WHERE中对字段用函数，例如LOWER(username) = ?会让索引失效；统一存小写，应用层处理大小写转换 - 登录失败记录需异步落库，避免高并发下
INSERT INTO login_attempts成为瓶颈；可用 Redis 先缓存失败次数，超限再写 MySQL
权限与角色关系务必用中间表，别硬编码字段
看到 users.role VARCHAR(20) 或 users.is_admin TINYINT 就该警觉——这类设计撑不过两个角色变更需求。RBAC 模型在 MySQL 中必须靠三张表落地，否则后期改权限逻辑等于重写业务。
- 三张表最低配：
roles（id, name）、permissions（id, code, description）、role_permissions（role_id, permission_id, PRIMARY KEY(role_id, permission_id)） - 用户-角色关联用
user_roles表（user_id, role_id），别在users表里加role_id字段——一个用户可能有多个角色 - 查某用户所有权限时，用
JOIN链路要控制深度，避免users → user_roles → roles → role_permissions → permissions全连；可预计算权限码集合存到 Redis，或用生成列缓存（MySQL 8.0+）
分页查询用户列表时，OFFSET 不是万能解
管理后台翻到第 100 页还用 LIMIT 20 OFFSET 2000？MySQL 得先扫出 2020 行再丢弃前 2000 行，I/O 和 CPU 成倍增长。这不是“数据量不大就没事”，而是随着用户数增长，响应延迟会突然恶化。
- 改用游标分页（cursor-based pagination）：基于上一页最后一条的
id或created_at做条件，例如SELECT * FROM users WHERE id > 12345 ORDER BY id LIMIT 20;
- 如果必须支持跳页（比如输入页码），给
id加覆盖索引：INDEX idx_id_status_created (id, status, created_at)，让排序和过滤都在索引中完成 - 千万级用户表，
COUNT(*)查总页数本身就很危险；前端显示“约 50 万用户”比精确数字更合理，可用TABLE_ROWS从information_schema估算（误差可接受）
实际最难的不是建索引或分表，而是让每个业务开发在写 SQL 时，心里清楚这条语句会在什么数据规模下崩——这需要定期看 EXPLAIN，而不是等监控报警才想起优化。
