禁止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 '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 空间。
Accessibility Review
下载
对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
- 禁用临时表：
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 后，务必用真实连接复现敏感操作。
