MySQL任何版本均禁止在存储函数中使用CREATE TEMPORARY TABLE，因函数需满足确定性与无副作用要求，而创建临时表会修改会话元数据、分配资源并破坏复制一致性，故解析阶段即报ERROR 1419或1370；存储过程则允许。
CREATE TEMPORARY TABLE 在存储函数中被禁止，不是 MySQL 5.7 的“不支持”，而是明确的语法限制 —— 任何版本的 MySQL 都不允许在存储函数（FUNCTION）中创建或操作临时表。
为什么存储函数里不能用 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 是允许的，但仅限标量赋值，无法存多行多列结果 —— 这正是临时表不可替代性的来源，也是限制存在的现实依据。
最容易被忽略的一点
很多人尝试用 PREPARE + EXECUTE 动态拼接 CREATE TEMPORARY TABLE 绕过检查，结果仍是失败：MySQL 在函数定义阶段就校验所有静态 SQL，动态 SQL 的语法合法性同样受制于函数上下文规则。真正生效的只有“不触碰会话级对象”的纯计算逻辑。
