MySQL不提供完整RBAC，但可通过users、roles、permissions、role_permissions、user_roles五张表实现解耦权限控制；登录时用JOIN查用户权限，校验逻辑应放应用层，MySQL账户权限与业务权限分层防护。
MySQL 本身不提供完整的 RBAC（基于角色的访问控制）功能，但可以通过合理的表结构设计 + SQL 权限管理 + 应用层逻辑，实现灵活、可扩展的用户权限控制系统。核心在于：把“用户”“角色”“权限”三者解耦，用关联表维护关系，再由应用控制具体操作的校验逻辑。
角色与权限的表结构设计
推荐采用经典的四张表结构，兼顾清晰性与扩展性：
- users 表：存储用户基础信息（id、username、password_hash、status 等），不直接存权限
- roles 表：定义角色（id、role_name、description），如 'admin'、'editor'、'viewer'
- permissions 表：定义细粒度权限项（id、code、name、module），如 'user:read'、'order:delete'、'dashboard:view'
- role_permissions 表：中间表，记录角色拥有哪些权限（role_id、permission_id）
- user_roles 表：中间表，记录用户被赋予哪些角色（user_id、role_id）
这样设计的好处是：角色可复用、权限可复用、支持多角色、支持动态增删权限，且不需频繁修改代码就能调整权限分配。
如何在 MySQL 中落地权限校验逻辑
MySQL 不适合在数据库层做业务级权限判断（比如“用户能否编辑这条订单”），但可以辅助完成两类关键任务：
-
登录认证与角色加载：用户登录后，用一条 JOIN 查询快速获取其所有权限 code：
SELECT DISTINCT p.code FROM users u
JOIN user_roles ur ON u.id = ur.user_id
JOIN role_permissions rp ON ur.role_id = rp.role_id
JOIN permissions p ON rp.permission_id = p.id
WHERE u.username = ? - 敏感操作的前置校验（可选）：对极关键操作（如删除管理员账号），可在存储过程中查 user_roles + role_permissions 做简单角色白名单判断，但建议主要逻辑放在应用层
配合 MySQL 用户账户权限做系统级隔离
别忽略 MySQL 自身的账户权限体系——它用于保护数据库访问本身，和业务权限互补：
- 为不同环境（dev/test/prod）创建独立 MySQL 用户，限制 host 和 database 访问范围
- 应用连接数据库时，使用最小权限账号（如只授予 SELECT/INSERT/UPDATE on app_db.*，不给 DROP 或 SUPER）
- 避免应用用 root 连接数据库；敏感库（如 mysql 系统库）禁止业务账号访问
这是安全底线，和你设计的 roles/permissions 表不冲突，而是分层防护：MySQL 账户权限管“能不能连上、能看哪些库”，业务权限表管“登录后能执行哪些功能”。
实际使用中的几个关键提醒
- 权限 code 建议统一规范（如 module:action），便于应用层用前缀匹配（如 'product:*'）、批量授权或前端按钮显隐控制
- permissions 表中加 is_enabled 字段，方便临时禁用某权限而不删数据
- user_roles 和 role_permissions 表务必加联合索引（如 (user_id)、(role_id)），保障查询性能
- 不要把权限判断全堆在 SQL 里（比如写超长 WHERE EXISTS 子查询去校验权限），易读性差、难调试、难复用
- 前端展示的菜单/按钮，应由后端根据用户权限列表动态生成，而非前端硬编码或仅靠 JS 判断——防绕过
不复杂但容易忽略。
