dense_rank比row_number更适合阶梯定价，因为它对并列销量值赋予相同档位且不跳号（如1,1,2,3），天然映射“同销量→同价格档”，而row_number强制唯一编号（1,2,3,4）会将并列商品错误分入不同档位，破坏阶梯定价的语义连续性。
为什么DENSE_RANK比ROW_NUMBER更适合阶梯定价
因为阶梯定价需要「相同销量区间对应同一价格档位」，而DENSE_RANK对并列值不跳过后续序号，能天然映射“销量并列→价格同档”。比如销量都是1000的3个商品，用ROW_NUMBER会分出1/2/3档，但DENSE_RANK统一给1，下一批次哪怕销量只差1，也稳进第2档——这正是阶梯定价要的“档位连续、不漏级”。
用DENSE_RANK按月销量分5档定价的写法
核心是把销量数值转成可排序的“档位依据”，常见做法是用FLOOR或区间分组再DENSE_RANK。直接对原始销量排名容易受极值干扰，所以先做销量分级：
SELECT
product_id,
monthly_sales,
DENSE_RANK() OVER (ORDER BY sales_level) AS price_tier,
CASE DENSE_RANK() OVER (ORDER BY sales_level)
WHEN 1 THEN 99.9
WHEN 2 THEN 89.9
WHEN 3 THEN 79.9
WHEN 4 THEN 69.9
WHEN 5 THEN 59.9
END AS unit_price
FROM (
SELECT
product_id,
monthly_sales,
FLOOR(monthly_sales / 200) AS sales_level -- 每200销量为一级
FROM sales_summary
) t;
-
FLOOR(monthly_sales / 200)把销量压缩成离散等级，避免单个爆款拉高整体档位分布 - 如果想按销量百分位切分（如Top20%为Tier1），改用
NTILE(5)更合适，但NTILE可能拆散相同销量值，DENSE_RANK+PERCENT_RANK组合更可控 - MySQL 8.0+、PostgreSQL、SQL Server 2017+ 支持；旧版MySQL需用变量模拟，逻辑复杂且不可靠
处理并列销量时价格档位意外跳档的问题
错误写法：DENSE_RANK() OVER (ORDER BY monthly_sales) 直接排原始销量——当有大量商品销量集中在某个值（如都是0或都是500），会导致前几档挤满，后面档位被大幅后移，实际只有3档生效。
- 真正要分档的是「业务定义的销量段」，不是原始数值本身，必须先归类再排序
- 用
CASE WHEN手动定义区间更直观：CASE WHEN monthly_sales ，再对此字段<code>DENSE_RANK - 注意NULL销量：未售出商品若参与排序，
DENSE_RANK默认把NULL排最前（不同数据库行为略有差异），建议加WHERE monthly_sales IS NOT NULL或用COALESCE(monthly_sales, 0)
和RANK、ROW_NUMBER混用时的陷阱
三者在并列值处理上完全不同：ROW_NUMBER强行编号（1,2,2,4），RANK跳号（1,2,2,4），DENSE_RANK紧邻（1,2,2,3）。阶梯定价只认最后一种。
- 如果误用
RANK，销量[100,200,200,300] → 档位[1,2,2,4]，中间缺了第3档，价格策略断层 - 聚合后再开窗易出错：比如先
GROUP BY product_id, month再算DENSE_RANK，必须确认OVER子句的ORDER BY字段未被聚合丢失精度 - Oracle中
DENSE_RANK()不能直接用于WHERE或HAVING，得套一层子查询或CTE，否则报ORA-30483
实际部署时，档位字段最好物化到商品主表或缓存，避免每次查价都实时计算窗口函数——尤其当销售数据量大、并发高时，DENSE_RANK的排序开销比普通索引查询高得多。
