NTILE按行数整除分配余数，分桶大小至多差1行，优先前面桶多1行；必须配合ORDER BY，NULL处理因数据库而异，不可嵌套窗口函数，性能依赖排序效率。
NTILE函数的基本行为和分组逻辑
NTILE 不是四舍五入式“平均”，而是按行数整除后分配余数——它把结果集按顺序切分成 n 个桶，编号从 1 开始，但各桶行数可能相差最多 1 行。比如 10 行数据用 NTILE(3)，会得到大小为 4、3、3 的三个桶（不是 3、3、4），因为 NTILE 优先让前面的桶多 1 行。
关键点：必须配合 ORDER BY 使用，否则行为未定义；且 ORDER BY 的排序依据直接影响分组边界——比如按销售额降序分 4 档，就是“最高 25%、次高 25%…”；反过来升序就变成“最低 25%”在第一组。
常见错误：NULL 值导致分组错位或报错
当 ORDER BY 表达式含 NULL，不同数据库处理方式不一：PostgreSQL 默认把 NULL 排在最前，SQL Server 默认排最后，MySQL 8.0+ 遵循标准（NULLS FIRST/LAST 可控）。这会导致同一语句在不同环境分组结果不一致。
- 显式控制
NULL位置：写成ORDER BY score DESC NULLS LAST（PostgreSQL/Oracle）或ORDER BY ISNULL(score, -999999) DESC（SQL Server 兼容写法） - 更稳妥的做法是提前过滤或填充：例如
WHERE score IS NOT NULL或用COALESCE(score, 0)替代原始字段参与排序
NTILE 与其它窗口函数嵌套使用的限制
NTILE 不能直接作为其他窗口函数的参数，比如 AVG(NTILE(4) OVER (...)) 是语法错误。若想统计每组均值，得先用子查询或 CTE 把分组结果固化：
SELECT group_id, AVG(sales) FROM ( SELECT sales, NTILE(4) OVER (ORDER BY sales) AS group_id FROM orders ) t GROUP BY group_id;
注意：如果原数据有重复排序键（如多个相同 sales 值），NTILE 仍会强行拆分——哪怕它们业务上应属同一档。此时需结合 DENSE_RANK() 或人工打标判断是否真需要“强制切割”。
性能隐患：大数据量下 ORDER BY 成为瓶颈
NTILE 必须完成全量排序才能编号，没有索引时 I/O 和内存开销陡增。尤其在 WHERE 过滤后仍有数十万行时：
- 确保
ORDER BY字段有索引，且索引覆盖了WHERE条件（例如CREATE INDEX idx_status_sales ON orders(status, sales)配合WHERE status = 'shipped'） - 避免在视图或复杂子查询里多层嵌套
NTILE，每层都触发独立排序 - 如果只是要“近似四分位”，且允许误差，可考虑用
PERCENT_RANK()+CASE判断，它不依赖严格排序，执行更快
真正难处理的是既要精确分组、又要高频查询的场景——这时候得权衡：是接受 NTILE 的排序成本，还是改用物化分组标识（如定时任务预计算并存到列中）。
