MySQL函数执行时内存暴涨，通常是临时表或排序导致的
MySQL在执行含
ORDER BY、
GROUP BY、
DISTINCT或子查询的函数（如自定义函数内嵌复杂逻辑）时，会隐式创建内部临时表。若数据量大且未走索引，InnoDB会先用内存（
tmp_table_size和
max_heap_table_size中的较小值）存临时结果，超限后自动落盘到磁盘临时表（
ibtmp1），引发IO和内存抖动。 检查是否触发磁盘临时表：
SHOW STATUS LIKE 'Created_tmp_disk_tables';值持续增长说明内存配置过低或SQL未优化 临时表内存上限不是全局固定值：它取
tmp_table_size与
max_heap_table_size的最小值，且该限制对每个连接独立生效 自定义函数（
CREATE FUNCTION）内部若循环调用
SELECT或拼接大量字符串（如
CONCAT累加），会持续占用线程私有内存，无法被其他连接复用
优化自定义函数内存的关键是避免在函数体内做集合操作
MySQL函数设计本就不适合处理多行数据——它是标量函数，每次只作用于一行。但很多人误在函数里写
SELECT ... INTO或用
WHILE遍历结果集，导致每调用一次就新建一个结果集上下文，内存不释放。 禁止在函数中使用
SELECT返回多行；如需查关联数据，改用参数传入ID，由外层SQL JOIN 替代 字符串拼接慎用
CONCAT循环：每次调用都分配新内存块，建议改用外层
GROUP_CONCAT()（并设置
group_concat_max_len合理值） 数值累加类逻辑（如计算层级路径）优先用递归CTE（MySQL 8.0+）或应用层处理，别塞进函数里反复申请变量空间
关键配置项必须按实际负载调，不是越大越好
盲目调高
tmp_table_size可能导致单个复杂查询吃光所有内存，尤其在高并发场景下线程数多，每个连接都按上限预分配，反而引发OOM Killer杀进程。 观察
SHOW STATUS LIKE 'Threads_connected';和平均查询复杂度，按公式估算：总内存 ≈
max_connections × min(tmp_table_size, max_heap_table_size)线上建议初始值设为 64M–128M（非OLAP场景），再根据
Created_tmp_tables/
Created_tmp_disk_tables比值调整：比值低于 10:1 就说明磁盘落地太频繁，可小幅上调
sort_buffer_size是每个排序操作独占的内存，不是每个连接独占——但它会在需要排序时立即分配，所以不宜设过高（一般 2M–4M 足够，除非明确有大字段
ORDER BY）
真正省内存的写法：把函数逻辑“推”到SQL层
多数所谓“函数需求”，其实用标准SQL就能更省内存地实现。MySQL的函数执行是解释型的，每次调用都要解析、校验、分配栈帧；而原生SQL走的是优化器+执行引擎路径，能利用索引、提前剪枝、向量化执行（8.0.33+）。
比如“获取用户最近订单状态”，别写函数get_last_order_status(user_id)，改用窗口函数：
SELECT user_id, status FROM (SELECT user_id, status, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) rn FROM orders) t WHERE rn = 1日期计算（如“距今X天是否过期”）直接用
NOW() - INTERVAL 7 DAY，别封装成函数——常量计算在优化器阶段就完成了，不消耗运行时内存 若必须用函数，确保其为
DETERMINISTIC并加上
READS SQL DATA显式声明，让优化器有机会做更激进的缓存判断
最易被忽略的一点：函数内调用
UUID()或
NOW()这类非确定函数，会导致整个函数被标记为不可缓存，每次调用都重新执行，连带其内部所有内存分配都无法复用。
