用户表和角色表必须用普通自增主键，不可用联合主键；仅在关联表（如t_user_role）中才适用联合主键，因其需唯一标识多对多关系且不被外部稳定引用。
用户表和角色表必须用联合主键还是普通主键？
必须用普通自增主键，别碰联合主键。联合主键在 t_user_role 这类关联表里才合理，但 t_user 和 t_role 本身是实体表，ID 要能被其他地方稳定引用——比如日志记录、缓存 key、外键约束。用 user_id BIGINT PRIMARY KEY AUTO_INCREMENT 最稳妥。
常见错误是把 username 当主键或加唯一索引就完事，结果登录态缓存用字符串做 key，后期改用户名时所有缓存失效；或者日志里只记用户名，查不到历史操作归属。坚持用数值型自增 ID，业务字段全走唯一索引。
-
username和email都要加UNIQUE约束，防止重复注册 -
password字段长度至少 128，留足 PBKDF2 或 bcrypt 哈希输出空间 - 加
status TINYINT控制启用/禁用，别物理删用户
权限表要不要区分 menu/button/api 三类？
要，但不是靠单独建表，而是在 t_permission 表里用 type 字段枚举。WinForm 场景下重点是 menu 和 button，api 可以后续扩展。不拆表，避免联查爆炸，也方便统一鉴权入口。
典型错误是把按钮当独立资源建表（比如 t_button），结果菜单树渲染要查 3 张表，按钮显隐判断要再 join 一次——性能掉得明显，代码也散。
type ENUM('menu', 'button', 'api') DEFAULT 'menu'-
code VARCHAR(64)必须唯一且语义化，如user:list、order:export:btn -
pid INT支持父子级联，菜单可嵌套，按钮挂菜单下，不用硬编码层级
t_user_role 和 t_role_permission 为什么不能合并成一张表？
因为语义和生命周期不同。用户换角色是高频操作，角色改权限是低频配置行为。合并在一张表里会导致：更新权限时锁住所有用户角色关系；查询某用户所有权限时多扫无效行；无法对「角色-权限」做批量授权/回收。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
更隐蔽的坑是：有人用 user_id + permission_id 当联合主键，绕过角色层——这直接破坏 RBAC 模型，失去角色复用能力，权限变更无法批量生效。
-
t_user_role：主键是(user_id, role_id)，无冗余字段 -
t_role_permission：主键是(role_id, permission_id)，可加created_at审计字段 - 两者都禁止出现
is_enabled这类状态字段——状态应落在用户、角色、权限三张主表上
MySQL 表名和字段命名该用下划线还是驼峰？
全小写下划线，别用驼峰。Windows 下 MySQL 不区分大小写，Linux 下严格区分，而 Java/MyBatis 默认按字段名反射，大小写错位直接报 org.apache.ibatis.reflection.ReflectionException。
实际项目里最常踩的是：建表用 userId，Java 实体用 userId，但 MyBatis XML 写成 user_id，结果查出来全是 null；或者 Navicat 导出 SQL 时自动转成大写，部署到 Linux 服务器就找不到表。
- 表名统一前缀，如
sys_user、sys_role，避免跟业务表混 - 字段名用
user_id、role_name、permission_code，保持一致性 - 索引命名带表名缩写，如
idx_sys_user_username，别用idx_uname这种缩写
真实上线时最容易被忽略的点：没给 t_user_role 和 t_role_permission 加复合索引。查某个用户的全部权限，SQL 是三层 JOIN，没索引的话，百万级数据下响应直接超 2 秒。必须确保 (user_id) 在 t_user_role 上有索引，(role_id) 在 t_role_permission 上也有索引——别只依赖联合主键的左前缀。
