ntile不能直接做用户分层，必须先聚合、再排序、最后分桶；必须配合order by，否则报错或结果无意义；排序字段和方向决定分层逻辑与层级含义；未聚合即分桶会按订单而非用户分层，导致失真；ntile(4)分不匀是设计使然，按“前余后匀”分配；mysql 5.7及更早版本不支持该函数。
NTILE 不能直接做用户分层，必须先聚合、再排序、最后分桶——跳过任意一步，分层就失真。
NTILE 必须配合 ORDER BY，否则报错或结果无意义
SQL 标准强制要求 NTILE 出现在窗口函数中时带 ORDER BY。不写会报错（如 PostgreSQL 报 window function ntite requires an ORDER BY clause），MySQL 8.0 虽可能不报错但结果随机，毫无业务含义。
- 排序字段决定分层逻辑：按
total_amount排就是价值分层，按last_login_days_ago排就是活跃度分层 - 排序方向影响层级编号：
ORDER BY total_amount ASC时1是最低价值层；DESC时1是最高价值层 - NULL 值默认排在最前（ASC）或最后（DESC），若存在大量无效用户（如未下单用户
total_amount为 NULL），会集中到同一层，污染分层结果
用户指标没聚合就用 NTILE，结果全乱套
常见错误是直接对订单明细表 orders 跑 NTILE(4) OVER (ORDER BY amount)，这分的是“订单”不是“用户”。一个高消费用户可能有 10 笔订单，被拆进 10 行，NTILE 就会把他的多笔订单打散到不同层里。
- 正确做法：先用子查询或 CTE 按
user_id聚合出用户级指标，例如COUNT(*) AS order_cnt或SUM(amount) AS total_amount - 聚合后行数 = 用户数，此时
NTILE(4)才是对用户的等频分层 - 别在聚合前加
PARTITION BY user_id——那会让每个用户自己成一个分区，NTILE 永远返回1
NTILE(4) 分不匀是设计使然，不是 bug
10 个用户跑 NTILE(4) 得到的分布是 3,3,2,2，不是 3,3,3,1 或四舍五入均分。这是它“尽可能均匀分配”的定义：把 N 行从上到下切块，前 N % n 个桶多 1 行，其余桶大小一致。
- 总行数 101，
NTILE(4)→ 前 1 桶 26 行，后 3 桶各 25 行 - 总行数 3，
NTILE(4)→ 编号为1,2,3，第 4 桶为空，不会补 0 或跳过 - 如果某层只含 1 个用户（比如最高消费唯一），
NTILE仍给它编号4，不会合并到相邻层 - 想按固定阈值（如消费 ≥ 10000 为 VIP）分层，该用
CASE WHEN，硬套NTILE反而模糊边界
MySQL 5.7 或更老版本没法用 NTILE
MySQL 在 8.0 才支持窗口函数，5.7 及之前版本没有 NTILE。用变量模拟极易出错：排序不稳定、并发执行错乱、空值处理异常。
- 临时方案：导出数据到 Python/Pandas 用
pandas.qcut()或numpy.array_split()分层再回写 - 长期方案：升级 MySQL，或改用支持窗口函数的引擎（如 Doris、StarRocks、PostgreSQL）
- 注意：即使 MySQL 8.0，
NTILE在大表（千万级以上）上性能敏感，建议先加索引在排序字段上，或先用LIMIT验证逻辑
真正难的不是写对那一行 NTILE(4) OVER (ORDER BY ...)，而是判断「这个指标是否已完成用户粒度聚合」「排序依据是否匹配当前业务目标」「分层结果是否会被 NULL 或长尾数据扭曲」——这些地方一错，后面全白算。
