窗口函数在存储过程中不能裸用，必须封装为子查询或cte；where无法直接引用窗口别名，需外层过滤；row_number()不可赋值给变量，且依赖order by和索引优化。
窗口函数在存储过程中执行时无法被提前过滤
存储过程里写的 SELECT 语句，其 WHERE 条件在窗口函数计算前就已生效，但如果你把过滤逻辑写在窗口函数内部（比如想用 ROW_NUMBER() 编号后直接 WHERE rn = 1），那必须靠子查询或 CTE 封装——否则语法报错或逻辑错位。这意味着：原表数据先全量扫描、排序、编号，再外层过滤，中间结果集可能远超最终需要的行数。
常见错误是写成：
SET @rn = (SELECT ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) FROM logs);
这会直接失败；正确做法是先用 CREATE TEMPORARY TABLE 或 WITH 把编号结果存下来，再查。
- 大表上没加
WHERE就开窗，等于强制全表排序，I/O 和内存压力陡增 - 分区字段（
PARTITION BY）若无索引，MySQL 8.0+ 会回表或临时文件排序，慢得明显 - ORDER BY 字段含大量 NULL 或重复值，会导致排序不稳定，触发额外去重逻辑
ROW_NUMBER() 在存储过程里不能直接赋值给变量
ROW_NUMBER() 是窗口函数，不是标量表达式，不能出现在 SET、SELECT ... INTO 或 INSERT ... SELECT 的目标字段位置，除非整个查询结构明确返回单行单列——而窗口函数天然返回多行。
典型报错：FUNCTION ROW_NUMBER cannot be used in this context
- 想取“每组第一条”，必须用子查询套一层：
SELECT * FROM (SELECT ..., ROW_NUMBER() OVER (...) AS rn FROM t) t2 WHERE rn = 1 - 临时表建表时要显式包含
rn列，再INSERT INTO tmp SELECT ..., ROW_NUMBER() ... - 别在存储过程里反复调用同一窗口逻辑，用
WITH提前定义一次，后面复用
ORDER BY 不写 NULLS LAST 容易让脏数据排第一
MySQL 虽不支持标准 NULLS LAST 语法，但 ORDER BY created_at DESC 会让 created_at IS NULL 的记录排最前，导致 ROW_NUMBER() = 1 指向无效数据。
正确写法要主动排除或调整顺序：
- 优先在
WHERE过滤掉：WHERE created_at IS NOT NULL - 或用表达式兜底：
ORDER BY (created_at IS NULL), created_at DESC（MySQL 兼容） - PostgreSQL/Oracle 用户记得加
NULLS LAST，否则排名逻辑和业务预期对不上
分页清洗大表时 OFFSET + LIMIT 会越来越慢
千万级日志表做批量清洗，如果用 LIMIT 10000 OFFSET 100000，每次都要跳过前面所有行，扫描成本线性增长。窗口函数能解决，但要注意写法：
- 必须预计算行号：
ROW_NUMBER() OVER (ORDER BY id)，再用WHERE rn BETWEEN 100001 AND 110000 - ORDER BY 字段必须有索引，否则
ROW_NUMBER()自身就变成性能瓶颈 - 避免在子查询里嵌套多层窗口，MySQL 8.0 对嵌套深度敏感，容易触发临时表或内存溢出
真正卡住的点往往不是窗口函数本身，而是没意识到它依赖排序的物理成本——你写的那条 OVER (PARTITION BY x ORDER BY y)，背后就是一次全量排序操作。
