怎样在MySQL中配置只允许创建临时表但不能建物理表的用户-mysql教程-PHP中文网

CREATE TEMPORARY TABLES权限独立于CREATE权限，需显式授予且必须与SELECT权限作用域一致（如均限定在app_db.*），否则执行CREATE TEMPORARY TABLE ... AS SELECT会报错ERROR 1142。

怎样在mysql中配置只允许创建临时表但不能建物理表的用户

只给 `CREATE TEMPORARY TABLES` 权限，不给 `CREATE`

核心就是权限分离：MySQL 把建临时表和建普通表拆成两个独立权限。只要不授 CREATE，用户就无法执行 CREATE TABLE；但只要给了 CREATE TEMPORARY TABLES，就能建临时表。

常见错误是误以为“只读用户默认不能建临时表”，其实恰恰相反——很多新用户没显式禁用 CREATE，结果意外获得了建物理表的能力。

必须显式授予 CREATE TEMPORARY TABLES，它不会随 SELECT 自动附带
绝对不要授 CREATE 权限（哪怕只在某个库），否则用户可建真实表
如果用户已有 ALL PRIVILEGES 或 GRANT OPTION，得先 DROP USER 重建，或用 REVOKE CREATE ON ... 清理

`GRANT` 语句必须限定到具体数据库

权限作用域错配是报错 ERROR 1142 (42000): CREATE TEMPORARY TABLES command denied to user 的最常见原因。MySQL 要求 CREATE TEMPORARY TABLES 和 SELECT 必须在同一作用域（比如都写 `app_db`.*）才能配合使用 CREATE TEMPORARY TABLE t AS SELECT ...。

✅ 正确：GRANT SELECT ON `app_db`.* TO 'tmp_user'@'%'; GRANT CREATE TEMPORARY TABLES ON `app_db`.* TO 'tmp_user'@'%';
❌ 错误：GRANT CREATE TEMPORARY TABLES ON *.* TO ... —— 这会让用户能在 information_schema 等系统库建临时表，有潜在风险
⚠️ 注意：GRANT ... ON `app_db`.* 不等于 USE app_db；如果应用连接后执行跨库查询（如 SELECT * FROM app_db.orders JOIN log_db.events），临时表语句仍需在 app_db 范围内才有效

用户 host 匹配和认证插件要对得上

权限配置完连不上、或者 SHOW GRANTS 显示权限缺失，大概率是账号匹配失败，不是权限本身写错了。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

检查实际登录用的 host：用 127.0.0.1 连 ≠ localhost，MySQL 把它们当两个不同账号处理
MySQL 8.0+ 默认用 caching_sha2_password 插件，老客户端（如某些 Python MySQL 驱动）可能握手失败，报错像 authentication plugin cannot be loaded；建用户时加 IDENTIFIED WITH mysql_native_password BY 'xxx' 更稳妥
验证当前会话真正匹配的账号：SELECT CURRENT_USER();，再查它的权限：SHOW GRANTS FOR CURRENT_USER;

临时表能做什么、不能做什么要心里有数

临时表不是绕过只读限制的后门，它能力明确受限：

✅ 允许：CREATE TEMPORARY TABLE tmp AS SELECT ...、ALTER TABLE tmp ADD COLUMN（改结构不影响原表）
❌ 禁止：INSERT INTO real_table SELECT * FROM tmp（无 INSERT 权限）、DROP TABLE real_table、RENAME TABLE tmp TO other_tmp（MySQL 不支持重命名临时表）
⚠️ 特别注意：CREATE TEMPORARY TABLE ... AS SELECT 如果源查询含重复主键值，而你又显式定义了 PRIMARY KEY，MySQL 8.0+ 会直接报错——这不是权限问题，是数据约束冲突