取消DROP权限须同时禁用全局和数据库级DROP选项，仅关闭数据库级DROP无法阻止有全局DROP权限的用户删表；DELETE权限仅控制行删除，与DROP无关。
phpMyAdmin里取消DROP权限必须勾选「结构」权限组中的DROP复选框
用户仍能执行 drop table 或 drop database，往往是因为没注意到「结构」权限组里的 drop 选项被勾选了——它和「数据」权限组里的 delete 是两回事，不能混淆。
常见错误现象：用户只能查数据、不能删行，却意外删掉了整张表；或者明明只给了某库权限，却仍能删掉其他库的表。
- 进入「用户账户」→「编辑权限」→ 切换到「数据库」标签页（不是全局）
- 选择目标数据库后，在「结构」权限组中，确保
DROP未勾选 - 如果用户只需读写数据，
CREATE、ALTER、INDEX这些也建议关闭 - 改完务必点击「执行」，否则不生效
DELETE权限控制的是行级删除，不是表结构
DELETE 权限只影响 DELETE FROM table_name 这类语句，对表本身无威胁。但它常被误认为“危险操作”，其实真正该警惕的是 DROP 和 ALTER。
使用场景举例：后台运营人员需要清空日志表某天的数据，但不能删表、不能改字段、不能删其他表。
- 在「数据库特定权限」中，仅勾选
SELECT、INSERT、UPDATE、DELETE - 不要勾选
CREATE、DROP、ALTER、INDEX - 若连
DELETE都不该有（比如纯报表用户），就只留SELECT - 注意：即使没给
DELETE，用户仍可能用TRUNCATE TABLE清空表——这需要DROP权限，所以关掉DROP就能一并防住
全局权限里的DROP和数据库级DROP要分开处理
如果用户有全局 DROP 权限，哪怕你在某个数据库里取消了 DROP，他依然能删任意库的表。这是权限叠加逻辑导致的常见疏漏。
立即学习“PHP免费学习笔记（深入）”；
性能与兼容性影响：全局高危权限不会拖慢查询，但会放大误操作风险，尤其在多人共用 root 或管理员账号时。
- 先检查用户是否被授予了全局
DROP：进「用户账户」→ 点击用户名 → 查看「全局权限」部分 - 若已勾选，直接取消，并点击「执行」
- 再切换到「数据库」标签页，为每个具体数据库单独确认
DROP状态 - 特别注意：MySQL 8.0+ 支持角色（role），推荐用角色统一批量管理权限，避免逐个用户修改
撤销权限后记得验证，别信界面显示
phpMyAdmin 的权限界面有时会缓存旧状态，点完「执行」不代表立即生效；更关键的是，MySQL 的权限系统有延迟刷新机制。
容易被忽略的地方：权限变更后，用户当前连接仍保留旧权限，必须断开重连才生效。
- 用该用户账号重新登录 phpMyAdmin，尝试执行
DROP TABLE xxx，确认报错#1142 - DROP command denied - 同样测试
DELETE FROM xxx LIMIT 1，看是否允许或拒绝 - 如果权限没变，检查是否漏掉了「全局」或「数据库」任一层的
DROP设置 - 极端情况可手动执行
FLUSH PRIVILEGES;（需有RELOAD权限）
