CREATE TEMPORARY TABLES权限仅允许用户在当前会话创建临时表，作用域为库级或全局，不支持表级；需显式GRANT/REVOKE，不包含于ALL PRIVILEGES；临时表会话结束自动销毁，与普通表权限分离。
MySQL 中 CREATE TEMPORARY TABLES 权限的作用范围
这个权限只控制用户能否在当前会话中创建临时表（CREATE TEMPORARY TABLE），不影响普通表操作，也不影响其他会话或全局行为。临时表只对创建它的会话可见，会话结束自动销毁，所以它本质是“会话级隔离资源”，不是数据库对象意义上的持久结构。
常见误解是以为给 CREATE 权限就自动包含临时表能力——其实不包含。MySQL 把它单独拆出来，就是为了细粒度控制内存/磁盘临时资源的使用，尤其在共享实例中防止单个用户滥用 TEMPORARY 表导致 tmpdir 压力过大。
如何显式授予或回收该权限
必须用 GRANT / REVOKE 显式操作，不能靠 ALL PRIVILEGES 自动覆盖（除非你用的是旧版 MySQL 5.6 且未启用 sql_mode=STRICT_TRANS_TABLES）。
- 授予：
GRANT CREATE TEMPORARY TABLES ON mydb.* TO 'user1'@'localhost'; - 回收：
REVOKE CREATE TEMPORARY TABLES ON mydb.* FROM 'user1'@'localhost'; - 注意作用域：权限可按库（
mydb.*）、全局（*.*）或表级（mydb.mytable，但表级无效，MySQL 忽略）指定；临时表权限不支持表级粒度，设了也无效 - 执行后需
FLUSH PRIVILEGES;—— 仅当你直接改了mysql.user表才需要；正常用GRANT语句则自动生效
权限缺失时的典型报错和绕过风险
用户执行 CREATE TEMPORARY TABLE t1 AS SELECT ... 时，会直接报错：ERROR 1142 (42000): CREATE TEMPORARY TABLE command denied to user 'user1'@'localhost' for table 't1'。
但要注意：如果用户已有 CREATE 权限，他仍可创建普通表模拟临时行为（比如加前缀 tmp_、用完手动 DROP），只是无法享受会话自动清理、跨事务可见等特性。这不是权限漏洞，而是设计使然——MySQL 不阻止“自己管理临时性”，只限制内建机制。
另一个易忽略点：SELECT ... INTO OUTFILE 或 LOAD DATA INFILE 不受此权限约束，它们走的是文件系统路径校验逻辑，和临时表权限无关。
与 SQL_MODE 和存储引擎的隐式交互
某些场景下，即使有 CREATE TEMPORARY TABLES 权限，语句仍可能失败：
- 当
SQL_MODE含NO_AUTO_CREATE_USER（已弃用）或STRICT_TRANS_TABLES时，若SELECT子句含非法值（如超长字符串插入VARCHAR(10)），临时表创建会中断并回滚，报错看起来像权限问题，实为数据校验失败 - 使用
InnoDB作为临时表引擎时（MySQL 5.7+ 默认），需确保innodb_file_per_table=ON且磁盘空间充足；否则可能报ERROR 1030 (HY000): Got error 168 from storage engine，容易误判为权限不足 -
MEMORY引擎临时表受max_heap_table_size限制，超出会静默转成磁盘表（MyISAM），此时若用户没对应磁盘表权限，反而触发权限错误
真正卡住的地方往往不在权限本身，而在 tmpdir 可写性、磁盘配额、或引擎参数是否允许会话级资源申请——这些比 GRANT 一行命令更难排查。
