ntile分层不匀是因为它按行数机械均分而非按数值分布切分，总行数不能被桶数整除时前几桶多1行，且必须配合order by使用，否则无业务意义。
NTILE分层为什么总是不匀？
因为NTILE只按行数机械切分，不是按数值分布聚类。它先把结果集按ORDER BY排好序，再从上到下硬切：总行数除以桶数，余数部分全塞给编号小的桶。比如101行分4桶，结果是26、25、25、25——第1桶多1行，其余均等。这不是bug，是设计行为。
常见错误是以为NTILE(4)会自动把高消费用户归进“第4层”，其实它只认排序位置。如果没写DESC，最高消费用户可能落在最后一组，编号却是4，但业务上你想要的是“编号1=最高价值”。
- 必须显式写
ORDER BY amount DESC，否则分层语义完全反向 - NULL值默认排最前（ASC）或最后（DESC），大量NULL会集中挤进某一层，建议用
WHERE amount IS NOT NULL提前过滤 - 重复值不影响分桶逻辑，但相同金额的用户可能被分到不同桶——NTILE不保证同值同桶
怎么写才不会让高价值用户被分错层？
关键在排序字段和方向。你想让“消费高=层级高”，就得用ORDER BY sales_amount DESC；想让“风险低=层级高”，就得用ORDER BY risk_score ASC。顺序错了，整个分层就跑偏。
典型错误写法：NTILE(4) OVER (ORDER BY sales_amount)（默认ASC），结果是最低消费用户进第1层，最高消费用户进第4层——但你命名时说“第1层是VIP”，这就矛盾了。
- 先聚合再分层：比如按用户算总消费，得先
GROUP BY user_id，再套NTILE()，不能直接对订单表用 - 别在
OVER里写CASE WHEN排序，窗口函数不支持表达式作为排序依据 - 层级名称要映射业务术语，得在外层套
CASE WHEN ntile_group = 1 THEN 'VIP' ...，不能在窗口内做
MySQL 5.7 怎么模拟 NTILE？
MySQL 5.7 不支持窗口函数，硬用变量模拟NTILE(n)极易出错：变量初始化时机不稳定、并发执行结果不可复现、ORDER BY + 变量组合在某些版本会跳行。官方明确不推荐这种写法。
更稳妥的替代路径是：先用应用层（Python/Java）查出排序后数据，再按行号计算桶号；或者升级到 MySQL 8.0+。真要临时凑合，只能用两步：
- 第一步：
SELECT @rownum := @rownum + 1 AS row_num, user_id, amount FROM (SELECT user_id, SUM(price) AS amount FROM orders GROUP BY user_id ORDER BY amount DESC) t, (SELECT @rownum := 0) r - 第二步：用外部脚本或子查询算
FLOOR((row_num - 1) / total_rows * n) + 1，但total_rows需额外查一次，且无法原子化 - 注意：变量方式在LIMIT、JOIN场景下极易失效，线上环境慎用
什么时候该换掉 NTILE？
当你需要按固定数值边界分层（比如“消费≥10000为S级”），或者要求相同值必须同桶，或者要严格控制每桶最大行数，NTILE就不合适了。
NTILE本质是等频分层，不是等宽分箱。它不管你的数据长什么样，只管“我有N行，切成K份”。如果业务规则明确，优先用CASE WHEN；如果想按百分位动态切（比如Top 10%），用PERCENT_RANK()更准；如果真要等宽数值桶（如0–2500、2500–5000），PostgreSQL/Oracle可用WIDTH_BUCKET()。
- RFM里的F（频次）适合NTILE，因为目标是“每层人数均衡”
- 风控里的逾期天数分级，更适合
CASE WHEN overdue_days - 大数据量下NTILE性能差，因需全排序+两次扫描，千万级数据容易OOM，此时抽样用
WHERE MOD(id, 10) = 0更快
