高基数partition by列（如主键、uuid）导致谓词下推失效，因优化器无法保证语义安全；order by配合窗口聚合进一步阻断下推；窗口结果用于join或where时下推彻底失效；cte+窗口函数强制物化，使底层索引失效。
OVER子句含高基数PARTITION BY时，优化器不敢下推谓词
当PARTITION BY列的唯一值过多（比如主键、UUID、时间戳），优化器会放弃对窗口子查询的谓词下推——它无法确认下推后是否影响窗口函数语义，尤其当外层有WHERE条件依赖窗口结果（如rn = 1）时，更倾向于先物化整个窗口结果再过滤。
常见错误现象：EXPLAIN显示子查询扫描了全部8000万行，但实际只需要匹配某几个contactid的最新记录；执行计划里出现WindowAgg节点在Sort之后，且Sort输入行数等于基表总行数。
- MySQL 8.0 对
ROW_NUMBER() OVER (PARTITION BY x ORDER BY y DESC)不支持将x = ?下推到基表扫描，哪怕x上有索引 - PostgreSQL 在子查询含
OVER时默认不启用tencentdb_enable_push_pred，即使打开，也仅对等值连接谓词有效，不覆盖窗口内部过滤 - SQL Server 遇到
PARTITION BY OrderID这类单行分区，仍强制排序，此时下推已无意义——因为排序本身成了瓶颈，而非过滤时机
ORDER BY + 窗口聚合组合导致下推路径被阻断
OVER(PARTITION BY a ORDER BY b)结构会让优化器认为窗口计算必须基于完整有序集，因此拒绝把外层WHERE条件（如b > '2025-06-01'）下推到底层扫描。它怕提前过滤破坏累计值、排名或分布统计的正确性。
典型场景：想查“每个客户最近3笔订单的累计金额”，写成SUM(amount) OVER (PARTITION BY customer_id ORDER BY order_date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)，但外层加WHERE order_date >= '2025-06-01'完全没效果——优化器仍在全量排序后才截取窗口。
- 避免用
ROWS BETWEEN配合高选择性时间过滤；改用子查询先筛时间范围，再套窗口 - PostgreSQL 14+ 可尝试
LATERAL+FETCH FIRST 3 ROWS ONLY替代，部分场景能触发下推 - SQL Server 中，若
ORDER BY字段无索引，Sort运算符会占90%以上耗时，此时讨论谓词下推已不优先——先建索引比调优SQL更有效
窗口函数结果被用于JOIN或WHERE时，下推逻辑彻底失效
一旦rn、rank()等窗口结果出现在ON或WHERE中（如LEFT JOIN ... ON t1.id = t2.basesn AND t2.rn = 1），优化器就无法把rn = 1下推——因为rn是计算产物，不是基表字段，不能参与索引查找或早期过滤。
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
错误认知：“我在ON里写了t2.rn = 1，应该能限制t2只扫一行”。实际执行中，t2子查询仍全量计算所有rn，ON中的条件只是JOIN时的匹配逻辑，不改变扫描范围。
- 真正有效的做法是把过滤内提：
SELECT * FROM b WHERE create_time IS NOT NULL QUALIFY ROW_NUMBER() OVER (PARTITION BY basesn ORDER BY create_time DESC) = 1（MySQL 8.0.23+ 支持QUALIFY） - MySQL 8.0.22及更早版本只能拆成两层子查询，外层
WHERE rn = 1必须保留，但内层需显式加WHERE缩小输入（如WHERE basesn IN (SELECT DISTINCT contactid FROM a)） - 别依赖
/*+ PUSH_PRED */hint——含OVER的子查询几乎都会忽略该hint
CTE + 窗口函数嵌套让下推可能性归零
用WITH user_rank AS (SELECT ..., ROW_NUMBER() OVER (...) rn FROM t)定义CTE，再在主查询中WHERE rn = 1，这种写法在所有主流数据库中都等价于“强制物化”。优化器看到CTE就会放弃跨层下推，因为CTE默认不可内联（除非MATERIALIZED = FALSE且满足严格可内联条件）。
执行计划中若出现CTE Scan或Materialize节点，说明窗口结果已落地为临时结构，后续所有过滤都在内存/临时表上进行，底层表索引完全失效。
- MySQL 8.0 中，CTE默认
MATERIALIZED，即使你写WITH user_rank AS (NOT MATERIALIZED ...)，遇到OVER也会自动降级 - PostgreSQL 需显式设置
WITH RECURSIVE才可能内联，普通CTE + 窗口函数基本无解 - 最务实的绕过方式：不用CTE，改用派生表（
FROM (SELECT ...) AS t），并确保外层WHERE条件能被优化器识别为可下推的等值条件（如t.basesn = outer.id）
窗口函数不是语法糖，它是执行模型的分水岭。只要OVER存在，优化器就必须在“语义安全”和“性能最优”之间做硬性取舍，而它几乎总是优先保前者。所以别问“为什么不下推”，要问“哪部分逻辑可以剥离出窗口之外提前过滤”。
