phpmyadmin看不到mysql库主要是权限或配置问题：先检查当前用户是否有select权限，再确认phpmyadmin实际连接的mysql用户及hide_db/only_db配置是否误屏蔽mysql。
phpmyadmin看不到mysql库：先确认用户是否有select权限
phpmyadmin默认只显示当前用户有权限访问的数据库，mysql系统库也不例外。即使你用的是root账号登录mysql，如果该账号在phpmyadmin连接时被限制了权限（比如通过grant显式授权时漏掉了mysql），它就不会出现。
检查方法：在phpMyAdmin的SQL选项卡中执行：
SHOW GRANTS FOR CURRENT_USER();
看输出里是否包含类似GRANT SELECT ON `mysql`.* TO 'xxx'@'%' 这样的语句。如果没有，就不是界面问题，而是权限缺失。
- 临时验证：用命令行MySQL客户端以同一用户登录，执行
SHOW DATABASES;，如果也看不到mysql，说明是权限问题，不是phpMyAdmin配置问题 - 注意
CURRENT_USER()和USER()的区别：前者返回实际认证用户（含host），后者可能显示代理用户，权限检查必须用前者 - phpMyAdmin 5.2+ 默认隐藏
information_schema、performance_schema、sys等系统库，但mysql不在默认隐藏列表里——所以它不显示，基本就是权限或连接用户不对
phpMyAdmin连接用的是哪个MySQL用户？查$cfg['Servers'][$i]['user']
很多人以为“我登录phpMyAdmin时输的是root，那连的就是root”，其实不一定。phpMyAdmin支持两种连接模式：cookie认证（用户自己输）和配置文件预设认证（config或signon）。如果你的config.inc.php里写了$cfg['Servers'][$i]['user'] = 'pma'，那无论你在登录页输什么，后端都用pma这个账号连MySQL。
找到你的phpMyAdmin配置文件（通常是/etc/phpmyadmin/config.inc.php或./config.inc.php），搜索Servers段，重点看这几项：
立即学习“PHP免费学习笔记（深入）”；
-
$cfg['Servers'][$i]['auth_type']：如果是'config'，则直接读取下面的user/password；如果是'cookie'或'http'，才真正用你登录时填的凭据 -
$cfg['Servers'][$i]['user']：这个值才是实际连接MySQL的用户名，把它复制出来，在MySQL里查权限 -
$cfg['Servers'][$i]['hide_db']：检查有没有正则匹配到mysql，比如'^(information_schema|performance_schema|mysql)$'——这种写法会把mysql也干掉
给用户加mysql库权限要小心INSERT/UPDATE操作
给非root用户开mysql库的SELECT权限是安全的，但一旦加上INSERT、UPDATE甚至DROP，就等于给了用户改用户权限、删账号、绕过认证的能力。MySQL 8.0之后mysql.user表结构变化大，误操作容易导致整个实例无法登录。
最小必要授权命令示例（仅查看）：
GRANT SELECT ON `mysql`.* TO 'pma_reader'@'localhost';
- 不要用
GRANT ALL PRIVILEGES ON mysql.*，哪怕只是临时调试 - MySQL 8.0+ 的密码哈希存储在
mysql.user的authentication_string字段，直接UPDATE可能因格式错误锁死账号 - phpMyAdmin里点开
mysql库后，某些表（如user、db）默认禁止编辑，这是插件层保护，不是权限不够——别因此误判权限状态
phpMyAdmin 5.2+ 的mysql库显示逻辑变了
新版phpMyAdmin对系统库做了更细粒度控制，默认启用$cfg['Servers'][$i]['DisableIS'] = true;（禁用information_schema），但它不影响mysql。真正影响mysql显示的是$cfg['Servers'][$i]['only_db']和$cfg['Servers'][$i]['hide_db']两个配置项。
常见陷阱：
-
only_db设成数组但漏了'mysql'，比如['app_db', 'test_db']→mysql直接被过滤掉 -
hide_db用了PCRE正则但没转义点号，比如'^mysql$'是对的，但'^mysql.'会意外匹配mysql_backup甚至mysql本身（因.匹配任意字符） - 修改配置后没重启web服务器（Apache/Nginx）或没清浏览器缓存，导致行为没更新
最稳妥的排查路径：关掉所有hide_db和only_db，确认mysql能显示；再逐项加回，定位是哪条规则在起作用。
