为什么MySQL 5.7不支持在存储函数中使用临时表？-mysql教程-PHP中文网

mysql任何版本均禁止在存储函数中使用create temporary table，因函数需满足确定性与无副作用要求，而创建临时表会修改会话元数据、分配资源并破坏复制一致性，故解析阶段即报error 1419或1370；存储过程则允许。

为什么mysql 5.7不支持在存储函数中使用临时表？

CREATE TEMPORARY TABLE 在存储函数中被禁止，不是 MySQL 5.7 的“不支持”，而是明确的语法限制 —— 任何版本的 MySQL 都不允许在存储函数（FUNCTION）中创建或操作临时表。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

为什么存储函数里不能用 `CREATE TEMPORARY TABLE`

根本原因在于函数的**确定性（DETERMINISTIC）和可重入性要求**： MySQL 要求函数必须是“纯计算型”的，不能产生副作用（如修改会话状态、创建/销毁对象、影响事务一致性）。而 CREATE TEMPORARY TABLE 会： - 修改当前会话的元数据（information_schema 中新增表名） - 分配内存/磁盘资源（触发 tmp_table_size 判断与落盘逻辑） - 干扰复制一致性（临时表不写 binlog，但函数调用本身可能被记录为语句级事件） - 导致同一 SQL 多次执行时行为不一致（比如第二次调用因表已存在而报错 ERROR 1050: Table 'xxx' already exists）

所以 MySQL 在解析阶段就直接拒绝，错误信息固定为： ERROR 1370 (42000): execute command denied to user 'xxx'@'%' for routine 'xxx' 或更常见的是： ERROR 1419 (HY000): You do not have the SUPER privilege and binary logging is enabled... —— 实际并非权限问题，而是语法硬限制，哪怕你加了 SQL SECURITY DEFINER 和 SUPER 权限也无效。

`TEMPORARY TABLE` 在存储过程 vs 存储函数中的差异

这个区别常被混淆，但非常关键：

✅ 存储过程（PROCEDURE）允许 CREATE TEMPORARY TABLE，因为过程不被用于 SELECT 表达式上下文，不参与查询优化器的确定性推断
❌ 存储函数（FUNCTION）禁止所有 DDL（包括 CREATE、DROP、ALTER）和显式事务控制（START TRANSACTION、COMMIT），只允许 DML（SELECT/INSERT/UPDATE/DELETE）且仅限于普通表

替代方案：如何绕过函数内不能建临时表的限制

如果业务逻辑确实需要中间聚合或分步处理，可行路径只有两条：

把逻辑拆到存储过程中，用 OUT 参数或用户变量（@var）传递结果，再由外部调用方组合；例如：CALL calc_summary(@result); SELECT @result;
改用派生表（Derived Table）或 CTE（MySQL 5.7 不支持 CTE，但可用子查询模拟），例如把原本想存在临时表里的中间结果，直接嵌套进 SELECT ... FROM (SELECT ...) AS tmp
避免函数封装：把复杂逻辑留在应用层或视图中，函数只做原子计算（如字符串处理、数值转换）

注意：SELECT INTO @var 是允许的，但仅限标量赋值，无法存多行多列结果 —— 这正是临时表不可替代性的来源，也是限制存在的现实依据。