必须分开设计角色表和权限表，因其为多对多关系，合并在一张表会导致冗余、更新异常及复用困难；标准方案是roles、permissions、role_permissions三张表，权限用可读性强的字符串标识（如'user:read'），并辅以联合索引和递归继承表支持角色继承。
角色表和权限表要不要分开设计
必须分开。角色（role）和权限（permission）是典型的多对多关系，硬塞进一张表会导致数据冗余、更新异常，而且无法灵活复用权限。比如 can_delete_user 这个权限可能被多个角色共用，合并在一列里就只能靠逗号分隔——那后续查谁有这个权限、加权限、删权限全得用 LIKE '%can_delete_user%'，既慢又不可靠。
标准做法是三张表：roles（存角色名、描述）、permissions（存权限标识符、说明）、role_permissions（纯关联表，只有 role_id 和 permission_id 两个字段，加联合唯一索引）。
权限字段用字符串还是整数ID
用字符串（如 'user:read'、'order:write'）。整数 ID 看似节省空间，但实际开发中几乎没人靠数字记权限含义，调试、日志、配置都得查映射表，反而增加心智负担。字符串可读性强，还能天然支持层级表达（'api:v1:user:*'），也方便前端按前缀过滤。
- 权限字符串建议统一小写、用英文冒号分隔模块和操作，避免空格和特殊符号
- 不要在
permissions表里存“是否启用”字段——权限本身是静态定义，启停应由角色绑定关系控制 - 如果权限数量超几百，加
UNIQUE INDEX在code字段上，避免重复插入
角色继承怎么实现（比如 admin 继承 editor）
MySQL 本身不支持角色继承语法（像 PostgreSQL 的 INHERIT），得靠应用层或额外表模拟。最稳妥的是加一张 role_inheritance 表，字段为 child_role_id 和 parent_role_id，查询时递归展开（注意深度限制，避免环引用）。
不推荐用视图或存储过程自动展开继承关系：一是 MySQL 8.0 以前递归 CTE 性能差，二是权限校验通常在应用连接池初始化或用户登录时做，提前展开并缓存更可控。
常见坑：
– 忘记检查循环继承（A→B→A），导致无限递归
– 把继承当成“默认权限”，结果用户直接绑了子角色却没获得父权限，其实是查询逻辑漏了递归JOIN
WHERE 条件里怎么高效查用户所有权限
别用子查询套子查询拼权限列表。正确姿势是：先查出用户所有直接角色 + 继承角色（一次 JOIN + 递归CTE 或应用层展开），再用这些 role_id 去 role_permissions 关联查权限，最后 LEFT JOIN permissions 拿字符串标识。
关键点：
– role_permissions 表必须有 (role_id, permission_id) 联合索引
– 如果用户角色数少（≤5），用 IN (1,2,3) 比 JOIN 更快；角色多时用临时表或 WITH 语句预存角色集
– 避免在 WHERE 里写 permission.code LIKE 'user:%'——这会让索引失效，应该让应用层把前缀转成具体权限码再查
权限模型看着简单，真正上线后最难调的往往是继承链断裂、权限缓存没及时失效、以及 DBA 顺手给 role_permissions 加了 ON DELETE CASCADE 却忘了级联删错表。留好日志字段（created_at、updated_by），比什么都强。
