窗口函数不直接使用索引，但order by和partition by字段影响执行计划；复合索引(user_id, created_at)可被复用以加速排序与分组，前提是索引顺序匹配且无隐式转换或函数包装。
窗口函数本身不直接使用索引，但ORDER BY和PARTITION BY字段影响执行计划
SQL优化器不会为 ROW_NUMBER()、RANK() 这类窗口函数单独建索引，但它会尝试复用现有索引加速 ORDER BY 和 PARTITION BY 的排序与分组过程。如果你的查询里有 OVER (PARTITION BY user_id ORDER BY created_at)，那么复合索引 (user_id, created_at) 很可能被用上——前提是该索引能覆盖排序+分组需求，且没有被隐式类型转换或函数包装破坏可索引性。
常见错误现象：EXPLAIN 显示 Using filesort 或 Using temporary，说明排序没走索引；或者 PARTITION BY 字段上没索引，导致每个分区都要全表扫描。
- 索引字段顺序必须严格匹配
PARTITION BY后接ORDER BY的列顺序（例如PARTITION BY a, b ORDER BY c, d→ 索引应为(a, b, c, d)） - 避免在
PARTITION BY或ORDER BY列上用函数，比如PARTITION BY YEAR(created_at)会让索引失效 - 如果窗口函数只用于取 Top-N（如
ROW_NUMBER() ），考虑用 <code>LIMIT+ 分组子查询替代，有时比窗口更高效
PostgreSQL 中 ROWS BETWEEN 范围对索引友好度差异大
PostgreSQL 对滑动窗口（如 AVG(amount) OVER (ORDER BY ts ROWS BETWEEN 10 PRECEDING AND CURRENT ROW)）的优化依赖排序字段上的索引，但仅限于 ROWS 模式；RANGE 模式因需值比较而非行偏移，几乎无法利用索引加速。
使用场景：实时滚动均值、移动平均线计算。若数据量大且 ts 有索引，ROWS 可以做到常数时间定位窗口边界；换成 RANGE 就可能触发每行都做范围扫描。
-
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW（累计求和）最易受益于ORDER BY字段索引 -
RANGE BETWEEN ...基本等价于“找所有值落在某区间内的行”，即使ts有索引，也常退化为索引扫描+逐行判断 - PostgreSQL 14+ 支持
WINDOW子句定义复用，但不改变底层索引行为，只是减少重复写法
MySQL 8.0+ 窗口函数索引支持有限，尤其涉及多表 JOIN 时
MySQL 的窗口函数执行引擎仍基于临时表+排序，即使 ORDER BY 字段有索引，JOIN 后的数据集也可能丢失原有顺序，导致索引失效。典型表现是 EXPLAIN 中出现 Using temporary; Using filesort，哪怕单表查询时索引生效。
参数差异：MySQL 不支持 WINDOW 命名复用（直到 8.0.29 才部分支持），且 PARTITION BY 若引用 JOIN 表字段，优化器往往放弃索引下推。
- 确保
ORDER BY字段来自驱动表（即 JOIN 左侧主表），否则排序无法复用索引 - 避免在窗口子句中混用聚合函数和非聚合字段（如
SELECT id, SUM(x) OVER(...), y FROM t），这会强制生成临时表 - 用
SELECT ... INTO @var或物化 CTE（WITH cte AS (SELECT ...) SELECT ...）有时比直接窗口更快，因为能控制中间结果大小
(group_id, ts) 索引，在加了 WHERE status = 'active' 且该字段无索引时，就可能让优化器弃用它。
