仅取消数据库级DROP权限仍可执行DROP DATABASE，因MySQL权限叠加生效：全局、数据库、表任一层级授予DROP即允许操作；GRANT OPTION权限更可让用户自授权限绕过限制。
为什么只取消数据库级 DROP 权限还不够
用户仍能执行 DROP DATABASE，往往是因为残留了全局权限——比如在 phpMyAdmin 的「Global privileges」里意外勾选了 DROP 或 CREATE。MySQL 的权限系统是叠加生效的：只要任意层级（全局 / 数据库 / 表）授予了 DROP，该操作就允许。更隐蔽的是，GRANT OPTION 权限本身不直接允许删库，但若用户能给自己加权限，就等于绕过限制。
必须清理的三个权限位置
以管理员账号登录 phpMyAdmin 后，按顺序检查并清空以下三处：
- 「Global privileges」区域：滚动到底部，**全部取消勾选**，尤其注意
DROP、CREATE、GRANT OPTION、SUPER - 「Database-specific privileges」→ 选择目标业务库（如
prod_orders）：确保DROP和CREATE**未勾选**；ALTER和INDEX也建议关掉，防结构篡改 - 「Table-specific privileges」→ 若已为某张表单独授过权（如
prod_orders.logs），需确认该表级权限中没有DROP
每改一处都点「执行」保存，别跳过。
验证是否真禁掉了删库能力
用该开发账号重新登录 phpMyAdmin，再开一个终端执行：
立即学习“PHP免费学习笔记（深入）”；
mysql -u dev_user -p -h localhost
然后依次尝试：
-
DROP DATABASE prod_orders;→ 应报错ERROR 1044 (42000): Access denied for user -
SHOW GRANTS FOR CURRENT_USER;→ 输出里不能出现ON *.*或ON `prod_orders`.*后跟着DROP -
SELECT SCHEMA_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'prod_orders';→ 这条应能查到，说明库可见性正常，只是删不了
如果 SHOW GRANTS 显示仍有 DROP，说明某处没清干净，或缓存未刷新——此时需用管理员账号执行 FLUSH PRIVILEGES;。
额外风险点：别忽略 information_schema 的副作用
即使删库被拦住，开发账号默认仍能查 information_schema.SCHEMATA，这意味着他能列出所有数据库名（包括其他团队的）。这不是漏洞，但属于信息泄露。若需收敛，得额外运行：
REVOKE SELECT ON information_schema.SCHEMATA FROM 'dev_user'@'localhost';
注意：这条命令会同时影响其查看自己库名的能力（SHOW DATABASES 依赖它），所以仅在严格隔离场景下使用；且执行后，该用户登录 phpMyAdmin 左侧导航树将只显示 information_schema 和自己被授权的那一个业务库——这反而是你想要的状态。
