NTILE必须带ORDER BY，否则SQL Server报错；排序决定“谁先进桶”，PARTITION BY实现分组独立切片，分桶不均等属正常行为，重复值需次级排序兜底。
NTILE必须带ORDER BY，否则直接报错
SQL Server 会明确拒绝没有 ORDER BY 的 NTILE 调用，错误信息是：Window function 'NTILE' requires an OVER clause with ORDER BY。这不是可选建议，是硬性语法要求。
排序字段决定了“谁先进桶”，而不是“按什么值分段”——NTILE(4) OVER (ORDER BY revenue DESC) 把高消费客户排前面，它们就自动落在第 1 桶；反过来用 ASC 就全反了。
- 多个排序字段可以写成
ORDER BY revenue DESC, customer_id ASC，避免相同数值被随机分配到不同桶 - NULL 值默认排在最前（
ASC）或最后（DESC），若要统一控制，加NULLS FIRST或NULLS LAST（SQL Server 2022+ 支持） - 别在外部查询再加
ORDER BY覆盖窗口排序——结果集顺序可能和桶编号错位，查出来“第1桶的人却排在最后”
用PARTITION BY实现每组内独立切片
想对每个部门、每个地区、每个产品类别的数据各自四等分？不能靠 GROUP BY，必须用 PARTITION BY。
错误写法：SELECT dept, NTILE(4) OVER () FROM emp GROUP BY dept——这既语法非法，又逻辑混乱：窗口函数和 GROUP BY 不能这么混用，且没指定排序。
- 正确结构是：
NTILE(4) OVER (PARTITION BY dept ORDER BY salary DESC) - 每个
dept内部单独计数、单独均分，互不影响。10人部门和50人部门都会得到 1–4 的桶号，但每组内的“第1桶”含义只在本部门内成立 -
PARTITION BY后不能再接全局排序；如果既要分组切片、又要整体排序展示，得用 CTE 或子查询两层处理
NTILE分桶不均等是正常行为，不是bug
107 行数据执行 NTILE(10)，你看到前 7 个桶各 11 行、后 3 个桶各 10 行，这是完全符合 SQL 标准的。它按行序切片，不是按值聚类，更不是四舍五入分配。
关键判断依据只有一个：总行数 ÷ 桶数 = 商 + 余数。余数多少，就有多少个桶会多出 1 行，且一定从前向后分配。
- 例如 103 行分 5 桶：
103 / 5 = 20 余 3→ 前 3 桶为 21 行，后 2 桶为 20 行 - 如果你需要每桶严格 ≤ K 行（比如抽样时控量），
NTILE不适合，改用(ROW_NUMBER() OVER (...) - 1) / K + 1 - 业务上真要“按消费额区间分档”（如 0–5k、5k–10k），别硬套
NTILE，该用CASE WHEN或PERCENT_RANK()配合阈值判断
重复值导致同值不同桶，得靠次级排序兜底
当多行 annual_revenue 完全相同时，NTILE 仍会把它们拆进不同桶——因为底层只认排序位置，不认业务语义。
比如 4 个客户都是 10 万元年消费，但排序后位置是 11、12、13、14，NTILE(4) 就会强行给它们分配 1、2、3、4 四个不同等级。
- 最轻量解法：加一个唯一字段做次级排序，如
ORDER BY annual_revenue DESC, customer_id - 若业务要求“同消费额必须同等级”，就得放弃
NTILE，改用DENSE_RANK()配合范围映射，或用PERCENT_RANK()算百分位后CASE划档 - 注意：加
PARTITION BY后，次级排序只在分区内生效，跨分区不保证唯一性
实际使用时，最容易被忽略的是“排序字段与业务目标的因果关系”——你不是在对数值分段，而是在对排序后的位置序列切片。桶号本身无绝对意义，它的业务解释完全取决于 ORDER BY 表达式的设计。
