窗口函数是否使用内存临时表取决于中间结果是否超出temptable_max_ram阈值；若created_tmp_disk_tables增长则已落盘，否则在内存中运行，但可能临近阈值边缘。
查清窗口函数是否真在用内存临时表
窗口函数（如 ROW_NUMBER()、RANK()、SUM() OVER()）在 MySQL 8.0 中默认会触发内部临时表，但具体走内存还是磁盘，不取决于 SQL 写法本身，而取决于中间结果集大小是否突破 temptable_max_ram 阈值。不能只看执行计划里有没有 Using temporary 就断定是参数问题——它可能只是逻辑标记，实际落盘位置由 TEMPTABLE 引擎调度。
验证方法：
执行带窗口函数的语句前，先清空状态：FLUSH STATUS;
再跑一次查询，立即查：SHOW STATUS LIKE 'Created_tmp%';
若 Created_tmp_disk_tables 增长 > 0，说明已落盘；若 Created_tmp_tables 增长但 Created_tmp_disk_tables 不变，才说明还在内存中跑（但不代表安全——可能刚卡在阈值边缘）。
确认 temptable_max_ram 是否被默认值卡死
MySQL 8.0.16+ 默认启用 TEMPTABLE 引擎处理内部临时表，它完全不看 tmp_table_size，只认独立参数 temptable_max_ram。这个值默认是总内存的 3%，上限 4 GiB。对窗口函数这类需要缓存整个分区数据的操作，极易超限。
- 查当前值：
SELECT @@temptable_max_ram;（单位字节） - 64 GiB 机器默认约 2 GiB → 窗口函数处理百万行 + 多列 VARCHAR/JSON，轻松突破
- 错误现象：查询变慢、
ibtmp1持续膨胀、错误日志出现The table '/tmp/#sql' is full（注意路径是假的，实际写的是ibtmp1） - 常见误操作：只调了
max_heap_table_size，却没碰temptable_max_ram，结果完全无效
窗口函数场景下，加索引比调参更治本
窗口函数的内存消耗主要来自「分区内排序 + 聚合」所需的中间结果缓存。如果 PARTITION BY 或 ORDER BY 字段无索引，MySQL 必须把整个分区数据读入内存排序；有覆盖索引时，InnoDB 可直接按索引顺序流式输出，大幅降低内存压力。
- 例如：
SELECT *, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY hire_date) FROM emp;
→ 建联合索引：INDEX(dept_id, hire_date) - 若含
JSON_EXTRACT()或表达式字段（如UPPER(name)），索引无效，必须提前物化或改写逻辑 -
EXPLAIN FORMAT=TREE中看到-> Sort row buffer或-> Window function下挂大子树，基本就是内存瓶颈点 - 避免在窗口函数中嵌套多层子查询或 JSON 解析——每层都放大中间结果体积
调参时必须同步控制 ibtmp1 膨胀风险
temptable_max_ram 调高能缓解内存不足，但一旦超限，数据全进 ibtmp1，而这个文件默认自动扩展、无上限。线上曾见 ibtmp1 涨到 955 GiB 占满磁盘，且只能靠重启释放。
- 必须配
innodb_temp_data_file_path=ibtmp1:12M:autoextend:max:2G（设硬上限） - 不要只依赖
temptable_max_ram—— 它管内存池，ibtmp1是兜底磁盘空间，两者要匹配 - 观察
ibtmp1实际增长：ls -lh /var/lib/mysql/ibtmp1，别信df -h /tmp（它根本不会写那里） - 存储过程里跑窗口函数，还要额外检查
max_heap_table_size和temptable_max_ram是否一致——前者影响显式CREATE TEMPORARY TABLE，后者影响窗口函数隐式临时表
窗口函数的内存行为不像普通 GROUP BY 那样容易预测，它的中间状态是“分区级缓存”，一旦分区过大或字段太宽，temptable_max_ram 就成了唯一闸门。很多人调完参数发现没用，其实是没意识到：这个值不是 per-query 的，而是整个 TEMPTABLE 引擎的全局内存池，所有并发查询共享——高负载下，一个大窗口函数就能吃掉大部分额度。
