SQL NTILE 能按金额均分用户吗？同分用户为什么会被分到不同桶？
面试怎么回答
我会先把数据聚合到目标用户粒度，再确认要均衡人数还是金额。NTILE尽量均分行数，会拆开边界上的同分用户，稳定排序只能固定拆分方式，不能消除这个取舍。如果要求同分同组，应改用明确阈值或按同分排名设计分层，并接受人数不均。每日动态分层还要保存版本，不能当作稳定实验分组。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
六位用户的金额是100、90、90、90、80、70，分成三桶，每桶两人。问题来了：三个金额都是90的用户，怎么可能既不拆开，又让每桶恰好两个人？
NTILE尽量均分的是排序后的行数，不是金额总量；人数均衡、同分同组和稳定分层是三个需要分别定义的目标。
先把一行代表谁说清楚
如果输入仍然是一行订单，NTILE分配的就是订单行，而不是用户。同一个用户有多笔订单，就可能出现在多个桶里。
因此先按统计周期和用户标识聚合出用于分层的金额，明确退款、币种和无消费用户是否纳入，再保证每用户一行。分层集合本身发生变化，后面的桶位也会变化。
例如只保留有消费的用户，与包含零消费用户的全量分层，回答的是不同业务问题。不能为了让SQL简单，把分母范围省略不讲。
NTILE均分的是行，不是金额
以下使用PostgreSQL 17的窗口函数语法，输入表已经满足每个用户一行：
SELECT user_id, amount,
NTILE(3) OVER (
ORDER BY amount DESC, user_id
) AS bucket_no
FROM user_amount
WHERE amount IS NOT NULL;它会尽量让各桶行数接近，不会保证每桶金额之和相等。头部一个高价值用户的金额，可能超过后面一整桶。
user_id作为并列排序字段，前提是它在本次集合内唯一且稳定。它可以使相同输入下的拆分有确定顺序，却不代表这个顺序在业务上更公平。
如果数据少于桶数，也不能期待每个编号都有用户。下游展示需要完整桶列表时，应另外补齐空桶，而不是把不存在的分组当成计算失败。
同分同组，会牺牲人数均衡
开头六个用户按金额降序分三桶，第一桶包含100和一个90，第二桶包含另两个90，第三桶包含80和70。这个结果符合按行均分，但不符合“同金额必须同一层”。
若业务要求同分同组，可以采用固定金额阈值，或先对金额取值建立不拆分并列组的边界，再映射用户。具体规则需要明确边界包含方向与极端分布的处理方式。
也可以借助排名或累计分布来制定规则，但不要把函数名直接等同于业务分层。大量用户同分时，某些分层可能很大，某些层可能为空；这不是所有目标都能同时满足的场景。
动态分桶不适合直接充当稳定分组
今天加入一批高金额用户，即使原用户金额没有改变，其排名和桶位也可能移动。NTILE依据当前集合计算，不承诺历史成员永远留在原桶。
如果要做每日用户价值画像，这种变化可能合理，但应保留统计日、统计窗口与分层版本。若要追踪一批原有高价值用户的后续行为，则应该固定入组时的标签，而不是每天重算成员。
实验分流更不能简单沿用每天变化的金额桶。实验单位、稳定分配与干预前信息需要单独设计，不能把业务画像分层和随机实验分组混为一谈。
一个典型场景：同样消费却拿到不同权益
假设业务把NTILE桶直接映射优惠等级，客服发现两个同金额用户得到不同权益，开发最初怀疑金额的小数精度或退款处理存在差异。
检查后金额完全相同，真正原因是并列用户横跨了桶边界。旧验收只验证每桶人数接近和总用户数一致，这两个条件恰好掩盖了权益公平性要求。
修正前先与业务确认目标：如果权益必须同分同档，就改成明确阈值并接受档位人数不均；如果只是分析报表分组，则保留人数均衡但清楚说明边界规则。
回归测试加入大量同分、全员零金额、人数少于桶数和新增用户等样本。技术上函数执行正确，不代表业务上分层规则已经正确。
资料与适用边界
机制以所链接版本为准；业务示例用于说明判断方法，不代表作者真实项目或已验证的生产性能。