ntile(n)将排序后结果集按行序均分为n个编号从1开始的桶，前余数个桶多1行；必须配合order by使用，不按值分布而按位置切分，相同值可能分属不同桶。
NTILE函数的基本用法和分桶逻辑
NTILE(n) 不是四舍五入分组，而是把结果集**按排序后顺序均分**为 n 个桶（bucket），编号从 1 开始。它不关心值的分布密度，只看行数——这是最容易误解的点。
必须配合 ORDER BY 使用，否则报错；也不能在没有窗口定义的普通查询中直接用（比如 SELECT NTILE(4) FROM t 会失败）。
- 若总行数不能被
n整除，前面的桶会多 1 行（例如 10 行分 4 桶 → 桶大小为 [3,3,2,2]） - 相同排序值可能被分到不同桶（因为 NTILE 只看位置，不合并相同值）
- 想按数值区间分桶（如 0–100 分 5 段），该用
CASE WHEN或WIDTH_BUCKET（Oracle/PostgreSQL），不是 NTILE
常见错误：ORDER BY 字段含 NULL 或重复值时的结果偏差
NULL 默认排在最前（ORDER BY x），会被优先塞进第 1 桶；如果大量 NULL 存在，会导致第 1 桶严重膨胀，后续桶变少甚至为空。
重复值本身不会导致错误，但会破坏“业务意义上的均匀”——比如按销售额排序，100 人中有 30 人销售额都是 0，这 30 行会按原始顺序（可能是插入顺序）被硬塞进前几个桶，和你预期的“低销人群集中归为一档”未必一致。
- 处理 NULL：显式写
ORDER BY COALESCE(sales, -1) ASC或ORDER BY sales ASC NULLS LAST（PostgreSQL/Oracle 支持） - 增强稳定性：加二级排序，如
ORDER BY sales DESC, user_id ASC，避免因执行计划变动导致桶内成员漂移 - 验证方法：查
COUNT(*) GROUP BY NTILE(4) OVER (ORDER BY sales)，确认各桶行数是否符合预期分布
和 PERCENT_RANK / NTILE(100) 的区别在哪
PERCENT_RANK() 返回的是相对排名（0 到 1 之间的小数），而 NTILE(100) 是强行切成 100 组、每组至少 1 行。两者语义完全不同。
例如 99 行数据跑 NTILE(100)，结果只有前 99 个桶有数据，第 100 桶为空；但 PERCENT_RANK() 仍能给每行算出一个有意义的百分位值。
- 要模拟“百分位分桶”（如 top 10% 算一档），别用
NTILE(10)，而应：CASE WHEN PERCENT_RANK() OVER (ORDER BY x) >= 0.9 THEN 'top10' ... -
NTILE(100)更适合“取前 N 名分 100 组做抽样”这类固定分组数场景，不是统计学意义的分位数 - SQL Server 和 PostgreSQL 对
NTILE的实现一致；MySQL 8.0+ 支持，但旧版不支持窗口函数，无法使用
实际分桶示例：按用户订单金额分 5 档并统计每档人数
注意这里不是按金额区间切，而是把所有用户**按订单总额从高到低排好，再顺次切成 5 段**：
SELECT
bucket,
COUNT(*) AS user_count,
MIN(total_amount) AS min_in_bucket,
MAX(total_amount) AS max_in_bucket
FROM (
SELECT
user_id,
SUM(amount) AS total_amount,
NTILE(5) OVER (ORDER BY SUM(amount) DESC) AS bucket
FROM orders
GROUP BY user_id
) t
GROUP BY bucket
ORDER BY bucket;
这个查询的关键在于子查询里先聚合（SUM(amount) GROUP BY user_id），再对聚合结果开窗。如果漏掉 GROUP BY 直接对明细行 NTILE(5) OVER (ORDER BY amount)，就变成了“把每笔订单分 5 档”，而不是“把每个用户分档”——这种层级错位是生产环境最常见的翻车点。
