应分别计算两期RANK()再JOIN对比：先用RANK() OVER(ORDER BY amount DESC)为各省销售额独立排名，再按省份FULL OUTER JOIN对齐，用COALESCE处理NULL，确保并列占位与空缺省份逻辑正确。

用RANK()两次计算再JOIN对比最直接

想分析各省份销售额排名的变动情况，核心思路其实很清晰：别试图“一次算出变化”，那容易把自己绕进去。更稳妥的做法，是分别计算出两期的RANK()排名，再把结果按省份对齐后进行比较。为什么非要分两步走？因为窗口函数本身并不跨行访问历史结果，RANK()也不会保存上下文信息，硬要在单个查询里“动态对比上期”，往往会掉进逻辑陷阱。

来看一个典型场景：假设你手头有sales_2023和sales_2024两张表（或者同一张表里带year字段），每行都包含province（省份）和amount（销售额）。目标很明确：算出“2024年相比2023年，各省排名到底升了还是降了，具体变动了几名”。

• 第一步，各自独立排名：必须分别对两期数据按销售额降序排列，使用RANK() OVER (ORDER BY amount DESC)。这里切记，别用ROW_NUMBER()——当销售额出现并列时，业务上通常要求名次一致，RANK()才能满足这个需求。
• 第二步，处理NULL值：这是关键细节。如果某个省份在2024年没有数据，LEFT JOIN后其2024年的排名就会是NULL，直接计算差值结果也会变成NULL。所以，必须用COALESCE(rnk_2024, 0)这类函数明确补位逻辑。
• 兼容性说明：这套方法在MySQL 8.0+、PostgreSQL、SQL Server、Oracle等主流数据库上都行得通。SQLite用户则需要3.25以上版本并确保窗口函数支持已开启。

处理并列排名与空缺省份的关键细节

真实业务数据里，销售额并列的情况并不少见（比如江苏和浙江都是1200万）。这时，RANK()会给出相同的名次（比如都排第3），而下一个名次则会跳到第5。这种“并列占位”的逻辑，恰恰是业务分析所需要的。但如果你不小心用了DENSE_RANK()，并列之后的名次会连续不跳号（变成3,3,4），反而会导致排名变化值失真——例如从第3名变成第4名，看起来只下降了1名，但实际上可能意味着被三个省份同时反超。

比并列更麻烦的是数据空缺。举个例子：2023年西藏有销售数据（排名第31），但2024年数据缺失。JOIN操作后，rnk_2024字段就会是NULL，如果直接计算rnk_2023 - rnk_2024，结果自然也是NULL。这种情况必须显式处理：

SELECT
  COALESCE(t1.province, t2.province) AS province,
  t1.rnk_2023,
  t2.rnk_2024,
  COALESCE(t1.rnk_2023, 999) - COALESCE(t2.rnk_2024, 999) AS rank_change
FROM (
  SELECT province, RANK() OVER (ORDER BY amount DESC) AS rnk_2023
  FROM sales_2023
) t1
FULL OUTER JOIN (
  SELECT province, RANK() OVER (ORDER BY amount DESC) AS rnk_2024
  FROM sales_2024
) t2 ON t1.province = t2.province;

这里有个技术要点：务必使用FULL OUTER JOIN，才能同时捕获到单边缺失的省份（比如今年新增的省份，或者去年有但今年退出的省份）。如果你的数据库不支持（比如MySQL），那就需要用UNION ALL等方式来模拟实现，只是逻辑会稍显冗长。

用CTE避免重复写RANK()，提升可读性

如果查询逻辑更复杂一些，比如需要先筛选（只看销售额大于500万的省份），或者后续还要进行聚合统计（例如计算“排名上升的省份总数”），那么把两期的RANK()计算封装进CTE（公共表表达式），会比写多层嵌套子查询清晰得多，也更容易复用：

WITH rnk_2023 AS (
  SELECT province, amount, RANK() OVER (ORDER BY amount DESC) AS rnk
  FROM sales_2023 WHERE amount > 500
),
rnk_2024 AS (
  SELECT province, amount, RANK() OVER (ORDER BY amount DESC) AS rnk
  FROM sales_2024 WHERE amount > 500
)
SELECT
  COALESCE(a.province, b.province) AS province,
  a.rnk AS rnk_2023,
  b.rnk AS rnk_2024,
  (COALESCE(a.rnk, 999) - COALESCE(b.rnk, 999)) AS delta
FROM rnk_2023 a
FULL OUTER JOIN rnk_2024 b ON a.province = b.province
ORDER BY delta;

注意一下这里delta值的正负含义：结果为正值，通常表示排名下降（因为2023年的名次数值更小、更靠前）；结果为负值，则表示排名上升。业务人员有时会混淆这个方向，所以一个实用的建议是：直接在字段别名里写清楚，比如命名为rank_change_2024_vs_2023，避免歧义。

性能和兼容性：小数据放心用，大数据注意索引

从性能角度看，RANK()作为窗口函数，执行时需要对数据集进行全量排序。如果单表数据量超过千万行，两次排序再加上JOIN操作，可能会遇到性能瓶颈。有几个很实际的优化点可以关注：

• 索引策略：确保在province和amount字段上建立联合索引，例如CREATE INDEX idx_p_a ON sales_2024 (amount DESC, province);。这虽然不能完全避免排序，但可以显著加速数据扫描过程。
• 数据库特性：在PostgreSQL中，可以考虑使用物化CTE（MATERIALIZED）来避免重复计算，不过MySQL目前不支持这个特性。
• 结果集限制：如果业务只关心排名变动最大的前10个省份，可以在每个CTE里加LIMIT 10。但务必注意：RANK()的排序计算必须在应用LIMIT之前完成，否则拿到的排名就是错误的。

最后，还有一个极易被忽略但至关重要的细节：并列处理的一致性。两年排名的ORDER BY表达式必须绝对一致，包括对NULL值的排序方式（如NULLS FIRST或NULLS LAST）。否则，即使销售额相同，省份在两年间的排名也可能因为NULL值顺序的默认规则不同而发生错位。最稳妥的做法是，即使数据里可能没有NULL，也显式地写上ORDER BY amount DESC NULLS LAST，把规则定死，杜绝后患。