dense_rank() 是分层归组的首选，因其保证同分同档且序号连续，避免rank()跳号或row_number()拆散并列数据；需搭配order by和显式null处理，且不能直接用于where过滤。
为什么 DENSE_RANK() 是分层归组的首选
DENSE_RANK() 天然适配“层级不中断”场景，比如按销售额划分 S/A/B/C 档：同分用户必须同档，且后续档位不能跳空。ROW_NUMBER() 强制唯一编号，会把并列数据硬拆进不同层；RANK() 虽支持并列，但跳号（如 1,1,3），导致第二档直接消失。实际业务中，一旦用错，就会出现“前两人并列第一，第三名被划进第三档”这种逻辑断裂。
常见错误现象：RANK() 在销售梯队统计中导致档位总数少于预期；或误用 ROW_NUMBER() + GROUP BY 伪实现分层，结果同分用户被随机打散到不同档位。
- 必须搭配
ORDER BY，且排序字段要真实反映分层依据（如ORDER BY sales DESC） - 不加
PARTITION BY是全局分层；加了则按指定字段（如部门）独立排档 -
DENSE_RANK()本身不控制总档位数，只保证序号连续——想切出固定档位（如 Top 5 档），得靠后续映射或分位点计算
如何用 DENSE_RANK() 实现固定档位数量（如 5 档）
直接 DENSE_RANK() OVER (ORDER BY score DESC) 只能生成连续自然排名（1,1,2,3,3,4…），无法限制最大档位为 5。强行用 NTILE(5) 会平均分配行数，可能把同分数据切到不同档，违背分层本意。
稳妥做法是先算出各档边界值，再用 CASE 划档，DENSE_RANK() 仅作辅助生成连续序号。
- 若接受“同分异档”，可用
NTILE(5) OVER (ORDER BY score DESC)，性能好但语义有损 - 若坚持“同分同档”，推荐先算最大排名：
MAX(rn) OVER()，再映射：ROUND(5.0 * (rn - 1) / NULLIF(MAX(rn) OVER(), 1), 0) + 1 - 注意边界：当全表
score全为NULL或空时，MAX(rn)为 0，NULLIF防止除零错误
多字段排序 + NULL 值导致分层错乱
DENSE_RANK() 对 NULL 的处理依赖数据库，默认行为不一致：PostgreSQL/Oracle 默认 NULLS LAST，MySQL 8.0 默认 NULLS FIRST 且不支持显式声明。一旦排序字段含 NULL，测试环境结果正常，上线后部分记录档位突变，往往就是 score 为 NULL 被排到最前或最后，拉高/压低了后续所有人的档位。
- 显式补全排序逻辑：例如
ORDER BY score DESC NULLS LAST（PG/Oracle 支持），MySQL 则需提前用COALESCE(score, -999999)替换 - 避免在关键分层字段上留
NULL：建表时设NOT NULL，或清洗阶段统一填充默认值 - 多字段排序时，
NULL影响会被放大——比如ORDER BY region, score DESC，region 为NULL的行会先被聚成一大块，再在其内部排score，极易扭曲区域维度的分层语义
窗口函数不能用于 WHERE 过滤，必须套子查询或 CTE
很多人一写 DENSE_RANK() 就报错，典型原因是把它当普通字段用在 WHERE 里：WHERE dense_rank() OVER (...) 直接触发 <code>ERROR: window functions are not allowed in WHERE。因为窗口函数执行时机晚于 WHERE、GROUP BY，早于最终 ORDER BY。
- 正确姿势：用 CTE 或子查询封装排名逻辑，外层再过滤，例如：
WITH ranked AS ( SELECT *, DENSE_RANK() OVER (ORDER BY sales DESC) AS dr FROM sales_records ) SELECT * FROM ranked WHERE dr
- 别在
GROUP BY后再套窗口函数——GROUP BY已压缩行数，窗口函数无原始行可算，结果全是 1 -
PARTITION BY不等于GROUP BY：它不减少行数，只重置计算上下文；想同时看明细和部门平均值，得用AVG(sales) OVER (PARTITION BY dept_id)，不是GROUP BY dept_id
复杂点在于，分层不是纯语法问题，而是业务语义、数据质量、数据库行为三者咬合的结果。哪怕 DENSE_RANK() 写对了，NULL 处理不对、分区键没索引、或忘了外层过滤封装，都会让整套逻辑在生产环境悄悄失效。
