NTILE(5)必须配合ORDER BY才能正确分档，否则按物理顺序切分导致结果不可控；需显式指定DESC排序使高值入第1档，NULL值默认排最前应过滤，且分组数不整除时前几组多1行。
NTILE(5) 必须配合 ORDER BY 才能正确分档
NTILE 函数本身不排序，只按输入的行序切分。如果没写 ORDER BY，数据库会按物理存储顺序分组，结果完全不可控——你可能把高信用分客户全分进第1档，也可能打散得毫无规律。
正确做法是先明确排序逻辑，比如按 credit_score DESC 从高到低排，再分5档：
SELECT customer_id, credit_score, NTILE(5) OVER (ORDER BY credit_score DESC) AS credit_tier FROM customers;
这样第1档是信用最高的20%，第5档是最低的20%（近似，因总数未必整除5）。
NTILE 分配不均时的常见现象和原因
当客户总数不能被5整除，NTILE 会优先让靠前的分组多1行。例如有102人，分5档的结果是：第1–2档各21人，第3–5档各20人。这不是 bug，而是 NTILE 的设计行为。
- 用
COUNT(*) OVER (PARTITION BY credit_tier)可验证每档人数 - 若需严格等量（如强制每档20人），NTILE 不适用，得改用
ROW_NUMBER()+ 算术取模或窗口计数再裁剪 - 注意 NULL 值：默认排在最前面（
NULLS FIRST），若credit_score有 NULL，它们会集中进第1档——建议提前用WHERE credit_score IS NOT NULL过滤
在 WHERE 或 HAVING 中不能直接引用 NTILE 别名
像 SELECT ..., NTILE(5) OVER (...) AS tier FROM t WHERE tier = 1 会报错，因为窗口函数执行晚于 WHERE。必须用子查询或 CTE：
SELECT * FROM (
SELECT
customer_id,
credit_score,
NTILE(5) OVER (ORDER BY credit_score DESC) AS credit_tier
FROM customers
WHERE credit_score IS NOT NULL
) t
WHERE credit_tier = 1;否则你会看到类似错误：column "credit_tier" does not exist 或 invalid reference to FROM-clause entry。
不同数据库对 NTILE 的 NULL 处理和排序默认值有差异
PostgreSQL 默认 NULLS LAST，SQL Server 和 Oracle 默认 NULLS FIRST。同一语句在不同库跑，NULL 值位置可能颠倒，影响分档边界。
保险起见，显式声明：
- 把 NULL 排最后：
ORDER BY credit_score DESC NULLS LAST - 把 NULL 当作最小值排最前：
ORDER BY credit_score ASC NULLS FIRST（但信用分场景通常不这么用） - MySQL 8.0+ 支持 NTILE，但旧版不支持，用前先查
SELECT VERSION()
真正麻烦的不是语法，是分档后业务怎么定义“第3档”——它到底是中等偏上还是中等偏下？这取决于排序方向和 NULL 处理，必须跟产品、风控对齐，不能只看 SQL 输出。
