窗口函数内存持续上涨需通过performance_schema查WORKSPACE_MEMORY_USED定位，超100MB即为元凶；ORDER BY无索引会强制全量内存排序，EXPLAIN出现Using filesort或Using temporary即为信号；WHERE中不可直接引用窗口别名，须用子查询/CTE隔离。
窗口函数执行时内存持续上涨，怎么确认是它在吃内存
直接查 SHOW PROCESSLIST 里状态为 Sending data 或 Copying to tmp table 的长时查询，再结合 INFORMATION_SCHEMA.PROCESSLIST 看 INFO 字段是否含 ROW_NUMBER()、RANK()、SUM() OVER 等关键词。更准的做法是开启 performance_schema 的语句事件采集：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_current', 'events_statements_history');
然后查：
SELECT THREAD_ID, SQL_TEXT, WORKSPACE_MEMORY_USED FROM performance_schema.events_statements_history WHERE SQL_TEXT LIKE '%OVER%' ORDER BY WORKSPACE_MEMORY_USED DESC LIMIT 5;
这个 WORKSPACE_MEMORY_USED 是 MySQL 8.0.28+ 才暴露的真实窗口计算内存用量，单位字节。如果单条 SQL 占用超 100MB，基本可以锁定问题来源。
ORDER BY 字段没索引，窗口函数会触发 filesort 并撑爆内存
窗口函数的 ORDER BY 不是“可选优化”，而是执行前提；但如果没有对应索引，MySQL 就必须把整个分区数据拉进内存排序——哪怕只取 ROW_NUMBER() = 1，也会全量加载。常见错误包括：
- 写
ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC)，但表上只有(dept_id)单列索引，缺(dept_id, salary)联合索引 - 用
ORDER BY created_at，但created_at是DATETIME类型且无索引，或有索引但被WHERE条件中的函数（如DATE(created_at)）破坏了索引下推 - 误以为
PARTITION BY自动加速，其实它只控制分组边界，不解决排序成本
验证方式：对目标 SQL 执行 EXPLAIN FORMAT=TREE，看输出里是否有 Using filesort 或 Using temporary；若有，且 rows_examined 远大于预期结果行数，就是排序内存失控信号。
WHERE 中直接引用窗口别名，导致执行计划彻底失效
比如写 SELECT *, ROW_NUMBER() OVER (...) AS rn FROM t WHERE rn ，MySQL 会直接报错 <code>Window function is not allowed in WHERE clause；但很多人改用子查询后仍踩坑：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY x ORDER BY y) AS rn FROM t) t1 WHERE rn
问题在于：如果外层 WHERE 没法下推，MySQL 可能先算完整个窗口（全表扫描 + 全局排序），再过滤。尤其当 PARTITION BY 字段基数低（如只有 3 个部门），而表有千万行时，内存峰值极易突破 1GB。
安全做法：
- 确保子查询中
PARTITION BY和ORDER BY字段都有联合索引，让 MySQL 能按分区流式计算，避免缓存全量 - 用 CTE 替代嵌套子查询（MySQL 8.0.1+ 支持），CTE 更容易被优化器识别为物化点，有时能提前截断
- 若只是取 Top N，优先考虑
LIMIT配合索引覆盖，而非窗口函数——例如 “每个部门薪资最高者” 可用SELECT DISTINCT dept_id, MAX(salary) FROM t GROUP BY dept_id+ 关联回查，比ROW_NUMBER()更省内存
日期字段缺失导致 ROWS BETWEEN 滑动窗口反复补空行
用 SUM(sales) OVER (ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) 做 7 日滚动和时，如果原始数据中某天没销售记录（date 缺失），MySQL 会按物理行数滑动，不是按日历天数。结果就是：本该 7 行参与计算的窗口，实际只用了 3 行，其余 4 行用 NULL 填充；而 SUM() 遇到 NULL 默认跳过，最终值偏小——开发为了“对齐”，可能加 COALESCE(sales, 0)，但这会让每行都变成非 NULL，内存中要维护更多中间状态。
更危险的是，如果配合 GENERATE_SERIES（MySQL 8.0.29+）强行补全日期，又没控制好范围，生成的临时序列可能达数万行，直接压垮内存。
建议：
- 先用
SELECT COUNT(*) FROM t WHERE date BETWEEN ...确认日期连续性，不连续就别硬上ROWS BETWEEN - 真要按自然日滚动，用应用层补日期 + LEFT JOIN，把窗口计算拆到内存更可控的地方
- 避免在大表上对
date字段做函数处理（如DATE_SUB(date, INTERVAL 6 DAY)），这会让索引失效，触发全表扫描
窗口函数不是银弹，它的内存开销是显式的、可测量的，但也是容易被低估的。真正难的不是写出语法正确的 SQL，而是判断“这一行 OVER 是否值得让数据库多扛 200MB 内存”。
