17370845950

禁止DROP DATABASE需REVOKE DROP ON db_name.；CREATE USER和GRANT OPTION必须ON .*收回；ALTER/INDEX/TEMPORARY TABLES等高危权限须单独撤销；权限生效需实测而非仅看SHOW GRANTS。

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 'd
  evuser'@'%';

  才有效；写成 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 后，务必用真实连接复现敏感操作。