不能在WHERE子句中直接使用RANK()或ROW_NUMBER()等窗口函数，因为SQL执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY，窗口函数仅在SELECT阶段计算，WHERE阶段尚未生成结果；必须用子查询或CTE先固化窗口函数结果。
子查询里用 RANK() 或 ROW_NUMBER() 为什么总报错？
直接在 WHERE 子句里调用窗口函数会报错，比如 WHERE RANK() OVER (ORDER BY sales DESC) —— 这是语法错误。窗口函数不能出现在 WHERE 或 GROUP BY 中，因为执行顺序上它们晚于这些子句。
正确做法是把排名逻辑放到子查询（或 CTE）里先算出来，再在外层过滤。例如：
SELECT * FROM (
SELECT name, sales,
ROW_NUMBER() OVER (ORDER BY sales DESC) AS rn
FROM orders
) ranked
WHERE rn
-
ROW_NUMBER()严格按顺序编号，相同销售额也会分出先后；RANK()对并列值给相同名次，但会跳过后续名次（如两个第1名后直接第3名） - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持；旧版 MySQL（5.7 及之前）不支持窗口函数，得用变量模拟，稳定性差
- 别在子查询里漏写
ORDER BY—— 窗口函数的排序必须显式声明，否则排名无意义
如何在多维度分组下做“每类 Top N”？
报表常要“每个部门销量前3的员工”，这时不能只靠外层 ORDER BY，必须用 PARTITION BY。
典型结构是：子查询内用窗口函数按组分区排名，外层按排名筛选：
SELECT dept, name, sales FROM (
SELECT dept, name, sales,
RANK() OVER (PARTITION BY dept ORDER BY sales DESC) AS rnk
FROM staff_sales
) t
WHERE rnk
-
PARTITION BY dept是关键，它让排名在每个部门内独立重置 - 如果用
ROW_NUMBER()而不是RANK()，遇到同分时可能把本该并列第2的人挤到第4，漏掉真实 Top 3 - 注意
PARTITION BY字段必须和你要分组的业务维度完全一致（比如别用dept_id却期望按dept_name分组）
子查询嵌套太深导致性能崩了怎么办？
三层以上子查询（比如先聚合、再排名、再关联维度表）会让优化器难以生成高效执行计划，尤其数据量过万后响应明显变慢。
优先用 CTE 替代嵌套子查询，语义清晰且多数引擎能更好优化：
WITH sales_ranked AS (
SELECT product_id, SUM(amount) AS total,
RANK() OVER (ORDER BY SUM(amount) DESC) AS rk
FROM sales
GROUP BY product_id
),
top_products AS (
SELECT product_id FROM sales_ranked WHERE rk
- CTE 不是视图，不会物化（除非加
MATERIALIZED提示），但可读性和调试性远高于多层括号子查询 - 避免在子查询里重复计算同一聚合（如多次
SUM()），提取到 CTE 里复用 - 如果外层还要
JOIN大表，确保product_id等关联字段有索引，否则WHERE rk 的结果集虽小，关联时仍可能全表扫描
为什么按时间范围 + 排名组合查询结果总不对？
常见陷阱：先在子查询里加 WHERE date >= '2024-01-01'，再排名，看似合理，但若业务要求“历史累计销量 Top 10 中，哪些人在本月有销售”，就不能提前过滤时间。
关键在明确排名依据和过滤依据是否同一维度：
- 若排名基于“本月销量”，子查询里
WHERE放时间条件没问题 - 若排名基于“总销量”，但只要求“其中在本月有记录的人”，就得先取 Top 10，再用
EXISTS或JOIN补时间条件 - 错误写法：
SELECT * FROM (SELECT ..., RANK()... FROM t WHERE month='2024-04') WHERE rank —— 这实际是“本月内销量 Top 10”，不是“总榜 Top 10 里的活跃者”
真正要后者，得两步走：先取总榜 Top 10 ID 列表，再查这些 ID 在本月的明细。
