MySQL 中如何禁止用户执行 DROP DATABASE
直接 revoke
DROP权限即可，但要注意：该权限控制的是「对数据库对象的删除行为」，不是「是否能连上数据库」。如果用户已有
ALL PRIVILEGES ON *.*，必须先收回全局权限再精细化授权。
DROP权限作用于数据库级别（
ON database_name.*）或全局（
ON *.*），不作用于单表；删表靠
DROP TABLE，属于另一权限项 执行
REVOKE DROP ON `myapp`.* FROM 'appuser'@'%';后，该用户仍可删表（
DROP TABLE）、删视图，只要没被显式 revoke 若用户是通过角色（ROLE）获得权限，需对角色 revoke，再
SET DEFAULT ROLE刷新生效
禁止 CREATE USER 和 GRANT OPTION 的实操要点
CREATE USER和
GRANT OPTION是高危权限，误授会导致权限扩散。它们不能通过
REVOKE ... ON database_name.*收回，必须在全局粒度操作。 执行
REVOKE CREATE USER ON *.* FROM 'devuser'@'%';才有效；写成
ON mydb.*会报错「Access denied; you need (at least one of) the CREATE USER privilege(s) for this operation」
GRANT OPTION一旦存在，用户就能把自身拥有的任何权限转授他人，必须显式 revoke：
REVOKE GRANT OPTION ON *.* FROM 'reporter'@'10.20.%';revoke 后需执行
FLUSH PRIVILEGES;（仅当使用 grant 表直改时才强制需要；常规 revoke 命令自动刷新）
用最小权限原则限制 ALTER、INDEX、CREATE TEMPORARY TABLES
这些权限常被忽略，但组合起来足以让低权用户破坏性能或绕过约束。例如：
ALTER可修改表结构导致应用异常；
INDEX可建冗余索引拖慢写入；
CREATE TEMPORARY TABLES被用于中间计算，但滥用会耗尽 tmpdir 空间。 禁用临时表：
REVOKE CREATE TEMPORARY TABLES ON `sales`.* FROM 'etl_user'@'192.168.5.%';
INDEX权限独立于
CREATE，即使没
CREATE权限，有
INDEX也能建索引，务必单独 revoke MySQL 8.0+ 支持按列 revoke，但
ALTER、
INDEX等 DDL 权限只能按库或全局控制，无法细化到表或字段
权限变更后验证是否真正生效
别只信
SHOW GRANTS输出——它显示的是「当前账号被授予的权限语句」，不反映实际运行时权限（比如角色未激活、host 匹配失败、proxy user 干扰等）。 用目标用户连接后，手动测试关键操作：
DROP DATABASE test_db;应返回 ERROR 1044 (42000): Access denied for user... 检查权限实际生效路径：
SELECT * FROM information_schema.role_table_grants WHERE grantee = "'appuser'@'%'" OR role_in_hierarchy = "'approle'";注意 host 匹配优先级：MySQL 按
'user'@'192.168.1.%'→
'user'@'192.168.%'→
'user'@'%'顺序匹配，revoke 必须和 grant 时的 host 完全一致
权限回收不是一劳永逸的事，特别是涉及角色、代理用户、或者 MySQL Router / ProxySQL 中间层时，实际生效链路可能比预期多跳。每次 revoke 后，务必用真实连接复现敏感操作。
