phpMyAdmin 不支持 per-server hide_db，仅最后一个服务器配置的 hide_db 生效；应改用 only_db 配合 MySQL 权限隔离，或为每环境部署独立 phpMyAdmin 实例。
不能为每个服务器单独配置不同的 hide_db 规则——phpMyAdmin 不支持 per-server hide_db。 它只在 $cfg['Servers'][$i] 块内生效，但实际运行时只会应用**最后一个有效配置块**中的值，其余会被覆盖或忽略。
为什么 $cfg['Servers'][$i]['hide_db'] 在多服务器下容易失效
phpMyAdmin 的配置解析机制决定了：即使你为每个 $i 都写了 hide_db，最终生效的只有索引最大的那个（比如 $i = 3 的配置），前面的都会被丢弃。这不是 bug，是设计限制——hide_db 不是“每服务器独立策略”，而是“全局导航过滤开关”，只是恰好挂在 $cfg['Servers'][$i] 下而已。
- 常见错误写法：在循环中为每个服务器重复赋值
$cfg['Servers'][$i]['hide_db']，以为能各自生效 - 真实行为：后写的覆盖先写的，最后那个
$i的值胜出 - 后果：你可能发现只有一台服务器的数据库列表被隐藏，其他照常显示，且无报错提示
替代方案：用 only_db + 权限隔离组合实现“逻辑分组”
既然 hide_db 无法 per-server 生效，就换思路：让每个服务器连接一个专用 MySQL 用户，该用户只对目标库有权限，并配合 only_db 强制限定可见范围。
-
$cfg['Servers'][$i]['only_db'] = ['myapp_production'];—— 只显示这个库（数组格式，支持通配符如'myapp\_%'） - MySQL 层创建对应用户：
CREATE USER 'prod_reader'@'%' IDENTIFIED BY 'xxx'; GRANT SELECT ON `myapp_production`.* TO 'prod_reader'@'%'; FLUSH PRIVILEGES; - 这样即使
information_schema等系统库物理存在，用户也查不到，only_db还会阻止它出现在导航树里 - 比
hide_db更可靠，因为它是权限+配置双保险，不依赖正则匹配逻辑
如果硬要“模拟”不同 hide_db，只能靠服务端路由隔离
真正隔离的唯一办法，是让不同服务器走不同 phpMyAdmin 实例——即部署多个 phpMyAdmin 目录，每个目录的 config.inc.php 独立配置自己的 hide_db，并绑定到不同子域名或路径（如 phpmyadmin-prod.example.com 和 phpmyadmin-staging.example.com）。
- 每个实例只配一个
$cfg['Servers'][1]，避免多服务器配置干扰 -
hide_db写在对应实例的config.inc.php里，绝对生效 - 需额外维护 N 个配置文件和 Web 路由，但这是目前最稳定、可预测的方式
- 别指望通过修改
$cfg['NavigationTreeDbSeparator']或清空pma__userconfig表来绕过——那些只影响 UI 分组或用户偏好，不改变hide_db的作用域
复杂点在于：phpMyAdmin 的配置模型把“服务器连接”和“UI 过滤”混在同一层级，但它们的生命周期和作用范围根本不同。你得接受这个事实——不是配置写错了，而是它本来就不支持你想要的语义。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
