撤销用户CREATE和ALTER权限后仍能建表，是因为权限叠加生效、GRANT OPTION未撤、角色继承或CREATE TEMPORARY TABLES权限遗漏；必须全面检查并同步撤销DROP、INDEX等关联权限。
撤销用户 CREATE 和 ALTER 权限后仍能建表？检查 GRANT OPTION 和角色继承
MySQL 中直接 REVOKE CREATE, ALTER ON db.* FROM 'user'@'host' 不一定生效，常见原因是该用户被授予过 GRANT OPTION，或通过角色（MySQL 8.0+）间接继承了权限。权限撤销是“叠加式”的，不是覆盖式——只要任意一条 GRANT 语句给了 CREATE，用户就拥有它。
- 用
SHOW GRANTS FOR 'user'@'host'查所有显式授权，包括通过WITH GRANT OPTION授予的权限 - MySQL 8.0+ 要额外查角色：执行
SELECT * FROM mysql.role_edges WHERE TO_HOST = 'user'@'host'，再对每个角色运行SHOW GRANTS FOR ROLE 'role_name' - 撤销时必须明确指定作用域：
REVOKE CREATE, ALTER ON `db_name`.* FROM 'user'@'host'；漏掉数据库名（如写成ON *.*）会导致撤销失败或范围错误
ALTER 权限被绕过？注意 RENAME TABLE 和 TRUNCATE 的隐含依赖
ALTER 权限控制的是修改表结构，但用户仍可能通过其他方式达成类似效果。比如 RENAME TABLE 需要原表和目标表的 ALTER 权限（或 DROP + CREATE），而 TRUNCATE TABLE 实际上等价于 DROP + CREATE，因此需要 DROP 和 CREATE 权限——即使你只撤了 ALTER，没动 DROP 和 CREATE，用户照样能清空并重建表。
- 若要真正禁止结构变更，必须同时撤销
CREATE、DROP、ALTER、INDEX（影响ADD INDEX）、REFERENCES（影响外键操作） -
TRUNCATE无法单独授权，它依赖DROP；所以禁止建表的同时，务必确认DROP也已撤销 - 测试是否生效：用目标用户登录后执行
CREATE TABLE t1 (id INT)和ALTER TABLE t1 ADD c1 INT，观察是否返回ERROR 1142 (42000): CREATE command denied类错误
权限生效延迟？FLUSH PRIVILEGES 并不总是必要
MySQL 5.7 及以后版本中，大部分 REVOKE 操作会立即生效，无需 FLUSH PRIVILEGES；只有在直接修改 mysql.user 等系统表后才需要它。误用 FLUSH PRIVILEGES 不仅多余，还可能掩盖权限未正确撤销的问题——比如你忘了加 ON db.*，执行 FLUSH 后以为生效了，其实根本没 revoke 成功。
- 撤销后立刻用目标用户连接测试，比执行
FLUSH更可靠 - 如果用户使用连接池（如应用层 keep-alive 连接），旧连接仍持有撤销前的权限缓存，需等待连接断开或重启应用
-
FLUSH PRIVILEGES在 MySQL 8.0+ 对角色权限无效，角色权限由activate roles或会话变量控制
最小权限原则下，只读用户仍可能创建临时表
即使彻底撤销了 CREATE 权限，用户仍可创建 TEMPORARY TABLE，因为这是独立权限项 CREATE TEMPORARY TABLES。这常被忽略，导致“明明禁止建表却还能建临时表”——尤其在存储过程或复杂查询中，临时表会被自动创建。
- 必须显式撤销：
REVOKE CREATE TEMPORARY TABLES ON db_name.* FROM 'user'@'host' - 该权限默认不包含在
SELECT或USAGE中，但很多一键授权脚本会顺手加上，需回头检查 - 临时表本身不持久，但可能被用于数据中转、绕过视图限制，甚至配合
INSERT ... SELECT实现变相建表
权限体系是叠加的，不是开关式的；一个遗漏的 GRANT OPTION、一个未清理的角色、一条没撤掉的 CREATE TEMPORARY TABLES，都足以让“禁止建表”形同虚设。动手前先 SHOW GRANTS，动手后立刻换用户验证，别信“应该没问题”。
