ntile(4)不能直接当四分位数用，因其按行数等频分组而非按数值分布计算分位点，无法保证第1组对应≤25%分位值；真实四分位数需用percentile_cont等函数求阈值后再映射。
NTILE(4) 为什么不能直接当四分位数用
NTILE(4) 只是把数据行数平均分成 4 组，每组编号为 1–4，但它不看数值分布——哪怕所有用户消费都集中在 0–100 元，NTILE(4) 仍会强行切出 4 档，导致第 1 组和第 4 组的实际消费区间可能完全重叠。真正的四分位数（Q1/Q2/Q3）是基于值的分布计算的分位点，比如 25% 用户消费 ≤ Q1，而 NTILE 分组只保证每组约 25% 的行数。
常见错误现象：SELECT user_id, amount, NTILE(4) OVER (ORDER BY amount) AS quartile 返回的 quartile = 1 用户，其 amount 可能高达 800 元（如果数据量小、分布陡峭），这明显违背“Q1 是 25% 分位点”的业务含义。
先算 PERCENTILE_CONT(0.25/0.5/0.75)，再用 CASE 分层
PostgreSQL / SQL Server / Oracle / BigQuery 等支持 PERCENTILE_CONT 的引擎，应优先用它求真实分位点值，再做映射。这是唯一能对齐统计定义的做法。
-
PERCENTILE_CONT(0.25) WITHIN GROUP (ORDER BY amount)得到 Q1 值（注意：不是行号，是金额阈值） - 用子查询或 CTE 先算出 Q1/Q2/Q3 三个标量值，避免重复计算
- 主查询用
CASE WHEN amount 映射分层 - 若需兼容 MySQL（无
PERCENTILE_CONT），得用变量模拟或导出后用 Python/Pandas 计算，SQL 内原生不可靠
示例（PostgreSQL）：
WITH q AS (
SELECT
PERCENTILE_CONT(0.25) WITHIN GROUP (ORDER BY amount) AS q1,
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY amount) AS q2,
PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY amount) AS q3
FROM users
)
SELECT u.user_id, u.amount,
CASE
WHEN u.amount
<h3>NTILE(4) 在什么场景下可以凑合用</h3>
<p>仅当业务接受「按数量均分」而非「按金额分界」时可用，例如：需要给用户发限量邀请码，按活跃度排序后均匀抽 25% 人发 A 类码、25% 发 B 类码……此时关注的是人群比例，不是价值断点。</p>
- 必须加
ORDER BY，否则结果不可复现；推荐用复合排序，如ORDER BY amount DESC, user_id避免相同金额打乱分组 - 数据量较小时（如 NTILE(4) 分组大小差异可能达 ±1 行，但不影响整体比例逻辑
- 绝对不要用
NTILE(4)的结果去反推 Q1 数值——MIN(CASE WHEN nt = 1 THEN amount END)不等于四分位数
NULL 和重复值会让 NTILE 和 PERCENTILE_CONT 表现不同
NTILE 默认跳过 NULL（除非显式写 ORDER BY amount NULLS FIRST），而 PERCENTILE_CONT 在多数引擎中会报错或忽略 NULL —— 但行为不统一。BigQuery 把 NULL 当最小值处理，PostgreSQL 则默认排最后。
- 务必在计算前清洗：用
WHERE amount IS NOT NULL或COALESCE(amount, 0)显式声明策略 - 大量重复值（如上千用户 amount = 0）会导致
PERCENTILE_CONT返回非整数阈值（如 Q1 = 0.0），这时CASE判断仍成立，但业务上可能需单独定义“零价值用户”档位 - NTILE 对重复值按排序位置分配组号，相同 amount 可能跨两个组，造成分层边界模糊
真正难的不是写对函数，而是确认业务到底要“等量分群”还是“等值分界”——选错基础逻辑，后面所有分层标签都会失真。
