<p>CREATE TEMPORARY TABLES 是独立权限，不包含在 CREATE 或 ALL PRIVILEGES 中；需显式授权，如 GRANT CREATE TEMPORARY TABLES ON myapp_db.* TO 'app_user'@'%'; 权限缺失会导致临时表创建失败，且应用层报错可能隐匿真实原因。</p>
CREATE TEMPORARY TABLES 权限是独立开关
MySQL 的 CREATE TEMPORARY TABLES 权限不包含在 CREATE、INSERT 或 ALL PRIVILEGES ON database_name.* 里，哪怕你对某个库有全部操作权限，也默认没有临时表创建权。这是个常被忽略的「隐身权限」——DBA 手动授权时漏掉、自动化脚本没显式写、迁移后权限未同步，都会直接导致 CREATE TEMPORARY TABLE 报 Access denied; you need (at least one of) the CREATE TEMPORARY TABLES privilege(s)。
验证当前用户是否真有该权限：SHOW GRANTS FOR 'app_user'@'%';
如果输出里没出现 CREATE TEMPORARY TABLES，就确认缺失。
GRANT 语句必须显式声明且作用域匹配
不能靠 GRANT ALL ON mydb.* 带出来，必须单独加一行：
- 只允许在指定库建临时表（推荐）：
GRANT CREATE TEMPORARY TABLES ON `myapp_db`.* TO 'app_user'@'%'; - 允许跨库建（常见于 ORM 或多库查询场景）：
GRANT CREATE TEMPORARY TABLES ON *.* TO 'app_user'@'%'; - MySQL 8.0+ 用角色管理更安全：
CREATE ROLE 'temp_role';GRANT CREATE TEMPORARY TABLES ON *.* TO 'temp_role';GRANT 'temp_role' TO 'app_user'@'%';
注意：FLUSH PRIVILEGES; 不需要——只要用标准 GRANT 语句执行成功，权限立即生效；只有直接改 mysql.user 表才需手动刷。
应用层报错可能完全不提“权限”二字
框架会把底层权限错误包装成其他异常，容易误判：
- Django
.distinct()或带annotate()的复杂查询 → 底层生成临时表失败，抛出OperationalError: (1146, "Table 'mysql.#sql-xxx' doesn't exist") - Laravel
DB::statement('CREATE TEMPORARY TABLE ...')→ 封装为QueryException，堆栈里看不到原始权限信息 - MyBatis
<select>含子查询 +GROUP BY→ MySQL 优化器自动选临时表路径，卡在 prepare 阶段，日志只显示超时或空响应
遇到这类现象，先别调 SQL，直接查权限；否则可能白调半天索引或连接池配置。
WITH 子句不是万能替代，但可绕过权限限制
MySQL 8.0+ 支持 WITH，它不依赖 CREATE TEMPORARY TABLES 权限，因为 CTE 是查询级临时结果，非会话级对象：
WITH user_orders AS ( SELECT user_id, COUNT(*) cnt FROM orders WHERE created_at > '2026-01-01' GROUP BY user_id ) SELECT u.name, o.cnt FROM users u JOIN user_orders o ON u.id = o.user_id;
但要注意：
- CTE 不能跨多个独立语句复用（比如不能先定义再用两次 INSERT）
- 复杂嵌套或大数据量时，CTE 性能未必优于显式临时表（尤其涉及多次扫描）
- 如果业务逻辑本身依赖临时表的生命周期（如存储过程里反复读写），CTE 无法替代
真正棘手的是：权限问题常和 SELinux、tmpdir 空间、磁盘配额等底层问题混在一起。看到 Can't create table 或 Can't create/write to file，先确认是不是权限——再查 SHOW GRANTS，别一头扎进系统日志里翻 SELinux 策略。
