直接设置$cfg['allowuserdropdatabase'] = false;可隐藏“删除数据库”按钮，但仅限ui层，不影响drop table等sql执行，需配合mysql权限控制（如revoke drop on . from 'user'@'host'）及flush privileges才真正生效。
怎样让 phpmyadmin 界面不显示“删除数据库”按钮
直接关掉 $cfg['allowuserdropdatabase'] 就行，它控制的就是这个按钮的显隐，不是权限、不拦 sql、只影响 ui。
编辑 phpMyAdmin 的 config.inc.php（不是 config.default.php），在任意 $cfg['Servers'][$i] 配置之后加一行：
$cfg['AllowUserDropDatabase'] = false;
保存后清空浏览器缓存和 phpMyAdmin 的 session（比如删掉 /tmp/phpsess_* 或重启 PHP-FPM），否则旧界面可能还在渲染按钮。
常见错误现象：
- 改了
config.default.php—— 无效，phpMyAdmin 不读它 - 没清缓存，页面看起来没变化 —— 实际是浏览器或服务端 session 缓存了旧配置
- 以为关了这个就拦住所有 DROP —— 它对
DROP TABLE、DROP VIEW完全无效
为什么点了“SQL”标签页还能执行 DROP DATABASE
因为 $cfg['AllowUserDropDatabase'] = false 只隐藏数据库列表旁的「删除」链接，不干预 SQL 执行逻辑。只要 MySQL 账号有权限，手写 DROP DATABASE mydb; 就能成功。
真正起效的只有 MySQL 层权限控制：
-
REVOKE DROP ON `mydb`.* FROM 'user'@'%';—— 拦该库下所有表/视图/存储过程的 DROP -
REVOKE DROP ON *.* FROM 'user'@'%';—— 拦所有库的 DROP（含 DROP DATABASE） - 执行后必须
FLUSH PRIVILEGES;（MySQL 5.7 及更早版本必需）
验证是否生效：用该账号登录后执行 SHOW GRANTS;，输出里不应出现 GRANT DROP；再试 DROP DATABASE mydb;，应报错 ERROR 1142 (42000): DROP command denied。
想彻底禁用所有 DROP 类操作，光关按钮远远不够
按钮只是表象，真正的风险入口是 SQL 输入框、表结构页的「DROP」链接、甚至“操作”页签里的删除表按钮（某些老版本 4.8 之前仍存在）。
更实际的组合动作：
- 设
$cfg['ShowSQLQuery'] = false;—— 这会干掉整个「SQL」标签页，以及所有带 SQL 提交的按钮（包括表级 DROP） - 关掉高级模块：
$cfg['ShowDesigner'] = false;、$cfg['ShowRelationLinks'] = false;，减少暴露的元数据操作入口 - 在 Web 服务器层拦截敏感路径，例如 Nginx 中加：
location ~ ^/phpmyadmin/(server_privileges|db_operations|tbl_drop)\.php$ { return 403; }
注意：$cfg['ShowSQLQuery'] = false 也会屏蔽 SELECT 查询，普通用户只剩浏览、搜索等只读图形化操作。
最容易被忽略的细节：权限来源不止一个
你执行了 REVOKE DROP ON `mydb`.* FROM 'user'@'%'，但用户仍能删库？可能原因：
- 该用户有全局
ALL PRIVILEGES，而REVOKE没覆盖到*.*级别 - 用户属于某个角色（MySQL 8.0+），而角色本身有 DROP 权限 —— 查
SELECT * FROM mysql.role_edges WHERE TO_USER = 'user'; - 用户是数据库
OWNER（PostgreSQL 场景）或表DEFINER（MySQL 存储过程上下文），权限自动继承
所以别只信 SHOW GRANTS 输出，一定要用目标账号实测 DROP DATABASE 和 DROP TABLE。真要保险，得从账号创建阶段就按最小权限原则授，而不是事后补 revoke。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
