NTILE(n)是按行数大致均分排序结果的窗口函数，不按数值切桶；当总行数不能被n整除时，前几组多1行，相同值可能跨桶，本质是等频分层而非等宽分箱。
窗口函数里用 NTILE() 做等宽分组最直接
想把一列数值按大小平均分成 4 组（比如“前25%”“中上25%”…），NTILE(4) 是最省事的选择。它不看具体值分布，只按排序后行数机械切分，适合做粗粒度分层。
常见错误是误以为 NTILE() 按数值区间切分——它切的是“行数”，不是“值范围”。如果数据量不能被 4 整除，组间行数会差 1，但不会跳过任何行。
-
NTILE(4) OVER (ORDER BY score DESC)：按分数降序分 4 组，第 1 组是最高分段 - 若总行数 101，结果会是 26、25、25、25 行 —— 不是严格等宽，但最接近
- 不能和
WHERE混用再套NTILE()：先WHERE过滤，再对剩余行重新编号分组
需要按真实数值区间（如 0–60/60–80/80–100）就别用窗口函数硬扛
CASE WHEN 配合列值判断才是正解。窗口函数本身不提供“按值切桶”能力，强行用 ROW_NUMBER() 或 RANK() 去映射区间，逻辑绕且易错。
比如划分考试等级：score 在 [0,60) 为“不及格”，[60,80) 为“良好”，[80,100] 为“优秀”，直接写：
CASE WHEN score <p>这种写法清晰、可读性强，且数据库能高效走索引（如果 <code>score</code> 有索引）。</p>
- 避免用
NTILE()算出组号后再JOIN一张“组号→等级”表——多此一举，还可能因分组不均导致语义错乱 - 边界值（如正好 60）要明确归属，
和>= 60必须无缝衔接，否则漏数据
WIDTH_BUCKET() 是少数支持数值等宽分桶的专用函数（Oracle/PostgreSQL）
如果你用的是 Oracle 或较新版本 PostgreSQL，WIDTH_BUCKET() 能真正按数值范围等宽切桶，比如把 0–100 分成 5 档，每档宽 20：
一款AI工具，主要用于将PREQSTATION编码任务委派给Claude Code、Codex CLI或Gemini CLI，采用PTY安全执行（工作目录+后台+监控），适合需要提升相关任务效率的用户。
WIDTH_BUCKET(score, 0, 100, 5)
返回值是桶编号（1～5），超出上下界的数据会被归入第 0 或第 6 桶（取决于实现），这点必须查文档确认。
- MySQL 和 SQL Server 没这个函数，硬要用就得手写
FLOOR((score - 0) / 20) + 1，但要注意负数和边界处理 -
WIDTH_BUCKET()的第三参数是桶数量，不是桶宽度；第二、三参数是闭区间下界和开区间上界（PostgreSQL 行为），Oracle 则是闭区间，行为不一致 - 浮点数精度可能导致临界值进错桶，建议提前
ROUND(score, 2)再传入
分区键和排序对窗口函数结果影响极大
所有窗口函数都依赖 OVER 子句里的 PARTITION BY 和 ORDER BY。漏写或写错，结果可能完全不对。
比如按部门分组后各自做四分位：NTILE(4) OVER (PARTITION BY dept_id ORDER BY salary)。如果不加 PARTITION BY dept_id，就会全公司统一排序分组，失去部门内比较意义。
-
ORDER BY必须存在，否则NTILE()报错；NULL默认排最前，必要时用ORDER BY score DESC NULLS LAST控制 - 多个相同
ORDER BY值时，NTILE()分配可能不稳定（不同执行计划结果不同），如需确定性，加一个唯一字段如id作次要排序 -
PARTITION BY后数据量差异大时（如某部门只有 2 人却要NTILE(4)），会生成空组或组数不足，得提前过滤小分组
实际用哪一种，取决于你到底想要“按行数均分”还是“按数值范围切片”。前者选 NTILE()，后者优先 CASE，有原生支持再考虑 WIDTH_BUCKET()。最容易被忽略的是 PARTITION BY 的遗漏和 NULL 排序的默认行为——它们不会报错，但结果往往静默错误。
