必须同时撤销全局和数据库级DROP权限，因全局权限优先级高于数据库级，仅取消后者无效；还需检查多host记录并用SQL补救缓存遗漏。
在 phpMyAdmin 5.1 中撤销普通用户的 DROP 权限，必须同时处理「全局」和「数据库级」两处设置；只关掉其中一处，用户仍可能删表或删库。
为什么只在「数据库」标签页取消 DROP 还不够
常见错误是：进入「用户账户」→「编辑权限」→ 切换到「数据库」标签页 → 找到目标库 → 取消 DROP 勾选 → 点「执行」。这看似完成，但若该用户在「全局权限」区域仍勾选了 DROP，他就能对任意库执行 DROP TABLE 或 DROP DATABASE，完全绕过数据库级限制。
- 「全局权限」里的
DROP控制的是整个 MySQL 实例范围的删库/删表能力 - 「数据库」标签页的
DROP只约束对该库内对象的操作，不覆盖全局权限 - phpMyAdmin 5.1 的权限界面默认展开「全局」区域，但很多人会直接滚动到底部去点「数据库」，忽略顶部已勾选的危险项
正确操作路径：先清全局，再清库级
进入「用户账户」→ 找到目标用户 → 点「编辑权限」后，按顺序检查以下三处：
- 在「Global privileges」区域，找到「结构」权限组，确保
DROP未勾选（它和CREATE、ALTER同组） - 滚动到「Database-specific privileges」→「数据库」标签页 → 找到该用户已被授权的每个库 → 逐个点击右侧「编辑权限」→ 在新页面中取消「结构」组下的
DROP - 如果该用户有多个 host 记录（如
'user'@'localhost'和'user'@'10.20.30.%'），必须分别进各自行的「编辑权限」处理，不能只改一个
界面失效时用 SQL 强制回收更可靠
有时「数据库」标签页根本没列出你预期的库名——比如权限是早期用 GRANT 直接加的，但 phpMyAdmin 缓存未刷新。这时界面操作会漏掉，必须用 SQL 补救：
REVOKE DROP ON `target_db`.* FROM 'user'@'host'; FLUSH PRIVILEGES;
-
target_db必须与当初GRANT时的数据库名完全一致（含反引号） - 若不确定原始授权范围，先运行
SHOW GRANTS FOR 'user'@'host';查实 -
FLUSH PRIVILEGES不可省略，phpMyAdmin 5.1 不自动触发该操作
真正容易被忽略的是 host 匹配精度：哪怕只是把 'user'@'127.0.0.1' 忘在一边，那个连接就仍保有 DROP 权限——而应用日志里往往只显示 IP，不会告诉你具体用了哪个 host 元组连上的。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
