phpMyAdmin 不支持设置 MySQL 8.0 默认角色，因其界面仅展示角色绑定关系（mysql.role_edges），无 SET DEFAULT ROLE 入口；必须通过 SQL 窗口执行该语句并确保 host 精确匹配、权限充足、用户重连后验证 CURRENT_ROLE()。
phpMyAdmin 本身不支持设置 MySQL 8.0 的默认角色（SET DEFAULT ROLE），必须通过 SQL 窗口手动执行，否则用户登录后 CURRENT_ROLE() 始终返回 NONE。
为什么在 phpMyAdmin 的“用户账户”界面点不动“默认角色”
phpMyAdmin（截至 2026 年最新稳定版）的图形化用户管理界面只读取并展示 mysql.role_edges 表中的绑定关系，但完全不提供 SET DEFAULT ROLE 的操作入口。你看到的“Role”列只是静态显示该用户被授予了哪些角色，和是否激活无关。
常见误操作包括：
- 在“编辑权限”页勾选某个角色 → 这只是执行
GRANT 'role_name' TO 'user'@'host'，不激活 - 点击“重新加载权限” → 只刷新缓存，不触发角色激活
- 试图在“登录信息”或“账户限制”标签页里找开关 → 根本不存在
必须用 SQL 窗口执行 SET DEFAULT ROLE
登录 phpMyAdmin 后，切换到任意数据库（如 mysql），打开顶部的 SQL 标签页，粘贴并执行：
立即学习“PHP免费学习笔记（深入）”；
SET DEFAULT ROLE 'app_reader' TO 'dev_user'@'%';
注意以下硬性条件：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
'app_reader'必须已存在且已通过GRANT SELECT ON ... TO 'app_reader'@'%'赋权 -
'dev_user'@'%'必须与创建角色时的 host 完全一致（'dev_user'@'localhost'和'dev_user'@'%'是两个账号） - 执行者账号需具备
SYSTEM_VARIABLES_ADMIN或APPLICATION_PASSWORD_ADMIN权限（root 通常满足） - 执行后需让目标用户**断开重连**，
SELECT CURRENT_ROLE();才会返回非NONE值
验证是否真正生效，别信 SHOW GRANTS
SHOW GRANTS FOR 'dev_user'@'%' 在 phpMyAdmin 中永远只显示 GRANT 'app_reader'@'%' TO 'dev_user'@'%' 这一行，这是正常行为，不代表权限没生效。
要确认真实效果，必须在新连接中执行：
SELECT CURRENT_ROLE();
以及：
SHOW GRANTS FOR 'dev_user'@'%' USING 'app_reader';
后者才会列出 SELECT、USAGE 等具体权限。如果这一步报错 ERROR 3530 (HY000)，说明该角色未被授予该用户；如果返回空，说明 SET DEFAULT ROLE 没执行或 host 不匹配。
自动激活？别依赖 activate_all_roles_on_login=ON 和 phpMyAdmin
即使你在 my.cnf 里配了 activate_all_roles_on_login=ON，phpMyAdmin 的连接池（尤其是通过 HTTP 复用的连接）可能不会触发该机制，导致角色看似“自动激活”实则失效。
更可靠的做法是：保持 activate_all_roles_on_login=OFF（默认值），坚持用 SET DEFAULT ROLE 显式控制，避免权限意外叠加。这点在生产环境尤其关键——因为 phpMyAdmin 很少用于运维批量操作，它只是个调试入口，真正的角色绑定和激活逻辑应由部署脚本或 DBA 统一管理。
