MySQL 8.0+角色是部门权限管理的唯一合理起点，因原生不支持业务维度元数据；需显式CREATE ROLE、GRANT权限、SET DEFAULT ROLE激活，支持角色叠加与跨部门共享，权限变更需重连或手动SET ROLE生效。
MySQL 8.0+ 角色（ROLE）是实现部门权限管理的唯一合理起点
直接在 user 表里加 department 字段、或建 business_dept 表关联权限，都是错路——MySQL 原生不支持业务维度的权限元数据。角色（ROLE）是官方为解决“权限集合复用”问题引入的机制，它天然适配部门场景：一个部门 = 一套权限集合 = 一个角色。
实操要点：
- 角色本身不带密码、不能登录，只承载权限；必须用
CREATE ROLE 'marketing'显式创建 - 给角色授权时，
GRANT SELECT, INSERT ON crm.* TO 'marketing'，和授给用户语法完全一致 - 角色可嵌套：允许
GRANT 'marketing' TO 'marketing_lead'，但注意 MySQL 不支持循环嵌套（如 A→B→A 会报错ER_ROLE_GRANTED_TO_ITSELF） - 角色默认不激活，用户连接后需执行
SET ROLE 'marketing'才生效；生产环境建议在用户登录时自动激活，通过SET DEFAULT ROLE 'marketing' TO 'mkt_user'@'%'
部门内岗位差异靠「角色叠加」而非「单角色多级字段」
一个市场部有专员、主管、总监，权限不是靠“role_level=2”这种字段控制，而是用多个角色组合：比如 'marketing_base' + 'marketing_manager' + 'marketing_admin'，再按需授予用户。
为什么不用单角色+字段？
- MySQL 权限判断是布尔叠加，不是数值比较——
HAVING role_level >= 3这种逻辑根本不存在 - 字段方式无法被
SHOW GRANTS识别，审计日志里查不到真实权限上下文 - 权限变更需改表+FLUSH PRIVILEGES+重启连接，而角色叠加只需一条
GRANT或REVOKE - 示例：给总监账号赋权：
GRANT 'marketing_base', 'marketing_manager', 'marketing_admin' TO 'zhangsan'@'10.0.2.%'
跨部门协作权限必须显式授予，不可依赖“继承”
MySQL 没有“上级部门自动包含下级权限”的概念。财务部需要读市场部某张报表表，不能指望 GRANT 'finance' TO 'marketing' 实现，那是方向反了。
正确做法：
- 新建共享角色：
CREATE ROLE 'report_readonly' - 授表权限：
GRANT SELECT ON marketing.campaign_summary TO 'report_readonly' - 把该角色同时授给财务和市场相关人员：
GRANT 'report_readonly' TO 'caiwu_user'@'%', 'market_user'@'%' - 避免用
GRANT SELECT ON *.*开全局口子——哪怕只为临时查一张表，也必须精确到db.table
角色权限刷新与失效边界容易被忽略
角色权限变更后，已连接用户的会话不会自动更新。这不是 bug，是设计：MySQL 权限缓存在会话初始化时加载一次，之后全程不变。
这意味着：
-
REVOKE SELECT ON crm.leads FROM 'marketing'后，正在执行查询的市场部用户仍能完成当前语句，但新查询会报ERROR 1142 (42000): SELECT command denied - 用户必须断开重连，或手动执行
SET ROLE NONE; SET ROLE 'marketing';才能重新加载权限 - 如果用了
SET DEFAULT ROLE，重连后自动激活，否则每次连接都要SET ROLE - 不要在应用连接池里长期复用连接并期望权限“热更新”——连接池应配置合理的 idle timeout，让权限变更自然生效
