NTILE()分桶不均匀是设计使然，它按行数尽可能均分，多余行从第1桶起逐个补足；若需等频或等宽分桶，应选用PERCENT_RANK()+FLOOR()、WIDTH_BUCKET()或ROW_NUMBER()+COUNT()等替代方案。
为什么 NTILE() 常常分得“不均匀”
直接用 NTILE(4) 想把数据均分成四桶，结果发现各桶行数差 1——这不算 bug，是设计使然。NTILE() 只保证“尽可能均分”，当总行数不能被桶数整除时，它会把多余的行从第 1 桶开始逐个补上。比如 10 行分 4 桶，结果是 3,3,2,2，而不是你期待的按数值范围切分的“四分位”。如果你要的是基于 value 分布的等宽/等频区间（比如收入分段、评分等级），NTILE() 就不够用了。
实操建议：
- 先确认目标：是“等行数分桶”（适合排序后取 Top N 每组）还是“等区间分桶”（适合业务口径如“高/中/低价值客户”）
- 若需等频（每桶数据量接近），可用
PERCENT_RANK()+FLOOR()组合：例如FLOOR(PERCENT_RANK() OVER (ORDER BY score) * 4)得到 0–3 的四分位编号 - 若需等宽（如每桶跨度 100），改用
WIDTH_BUCKET()（Oracle/PostgreSQL 支持），或手动算：FLOOR((value - MIN(value) OVER()) / ((MAX(value) OVER() - MIN(value) OVER()) / 4.0))
用 ROW_NUMBER() + COUNT(*) OVER() 实现可控 Top-K 分桶
想把用户按最近订单金额分“头部 5%、中部 90%、尾部 5%”，但 NTILE(20) 不够精准——它只管行数，不管阈值。这时候得靠相对位置计算。
实操建议：
- 先用
ROW_NUMBER() OVER (ORDER BY amount DESC)排序编号，再用COUNT(*) OVER()得总数，两者相除即得累计占比 - 写法示例：
SELECT user_id, amount, CASE WHEN ROW_NUMBER() OVER (ORDER BY amount DESC) * 1.0 / COUNT(*) OVER() <= 0.05 THEN 'top_5p' WHEN ROW_NUMBER() OVER (ORDER BY amount DESC) * 1.0 / COUNT(*) OVER() > 0.95 THEN 'bottom_5p' ELSE 'mid_90p' END AS bucket FROM orders; - 注意：用
ROW_NUMBER()会导致并列值被强制拆开；若需保留并列（如相同金额同属 top），换用RANK()，但得重算分母逻辑（因为并列会跳号）
LAG()/LEAD() 辅助动态边界识别
有些分桶依赖相邻记录的差值判断，比如“连续 3 天登录算活跃用户”，或“价格突增 20% 触发警报桶”。这时单靠分组聚合不行，得看上下文。
实操建议：
- 用
LAG(value, 1) OVER (PARTITION BY user_id ORDER BY date)拿前一日值，再和当前行做差或比值 - 避免常见错误：忘记
PARTITION BY导致跨用户比较；或ORDER BY缺少唯一键，使窗口顺序不可靠（可加id保序） - 性能提示：这类操作无法下推到索引扫描，大数据量时建议先过滤再开窗，别在全表上套
LAG()
MySQL 8.0+ 和 PostgreSQL 的关键差异点
不是所有数据库都支持同一套窗口函数语义。比如 MySQL 8.0 虽支持 NTILE()，但不支持 WIDTH_BUCKET()；PostgreSQL 有，但默认不带 PERCENT_RANK() 的逆运算函数。
实操建议：
- MySQL 用户想实现等频分桶，只能手写子查询模拟：先算出各分位点值（用
GROUP_CONCAT+SUBSTRING_INDEX或多次LIMIT/OFFSET），再JOIN回原表打标 - PostgreSQL 用户可直接用
ntile()或width_bucket()，但注意width_bucket()对边界外值返回 0 或 n+1，需用CASE截断 - 共通陷阱：所有窗口函数必须出现在
SELECT或ORDER BY中，不能用于WHERE——想筛桶，得套一层子查询或 CTE
实际用窗口函数分桶，最难的不是语法，而是想清楚“桶”的定义到底依赖什么：是全局排序位置？是字段分布密度？还是相邻变化率？一旦定义模糊，再漂亮的 OVER() 子句也救不回来。
