NTILE分桶不均是设计行为而非bug，它保证各桶行数相差不超过1，余数行优先分配给编号更小的桶；必须配合稳定ORDER BY使用，不支持GROUP BY直接引用，且跨库兼容性需注意版本差异。
NTILE分桶结果不均是设计行为，不是bug
NTILE(n) 从不承诺“绝对等分”，它只保证各桶行数相差不超过 1，且余数行**一定优先分配给编号更小的桶**。比如 103 行数据用 NTILE(10)，前 3 个桶各 11 行，后 7 个桶各 10 行——这不是计算错误，是 SQL 标准明确定义的行为。
常见误操作是拿 COUNT(*) 分组后对比，发现第 1 桶比第 10 桶多一行，就怀疑写错。其实只要验证总行数 ÷ 桶数的商和余数，就能预判分布：⌊103/10⌋ = 10，余数 3 → 前 3 桶为 11，其余为 10。
- 别用“看起来不均匀”否定结果，先算
COUNT(*) OVER()再推导理论分布 - 如果业务硬性要求每桶严格相等（如抽样必须恰好 1000 条/桶），
NTILE不适用，得换ROW_NUMBER() % n或随机采样 -
NTILE(1)恒为全 1；NTILE(0)直接报错ERROR: invalid argument to NTILE()
ORDER BY 不稳定导致分桶漂移
当排序字段存在大量重复值（如几十万条记录 status = 'pending'），又没加唯一次级键，不同执行时物理行序可能变化，NTILE 就会把同一组值分到不同桶里——这不是函数问题，是排序本身不确定。
例如按 amount 降序分 4 桶，但 5000 条记录 amount = 0，它们可能某次全进第 4 桶，另一次被拆到 2～4 桶。解决方法必须显式加固排序：
- 在
ORDER BY中追加唯一列：ORDER BY amount DESC, order_id - NULL 值默认排最前，若
amount含 NULL，先用WHERE amount IS NOT NULL过滤，或用ORDER BY COALESCE(amount, -1) DESC统一归置 - 避免用函数表达式排序（如
ORDER BY UPPER(name)），否则无法走索引，性能雪崩
跨数据库兼容性踩坑点
NTILE 在 MySQL 8.0+、PostgreSQL、SQL Server、BigQuery、Snowflake 中语法一致，但旧版本和 SQLite 完全不支持——迁移脚本里直接写 NTILE(4) 在 MySQL 5.7 会报 FUNCTION xxx.NTILE does not exist。
SQLite 用户只能手写模拟逻辑：(ROW_NUMBER() OVER (ORDER BY x) - 1) / CAST((SELECT COUNT(*) FROM t) AS INTEGER) + 1，但要注意整数除法截断行为因引擎而异。
- SQL Server 默认
ORDER BY为 ASC，业务常需降序，漏写DESC会导致高值进末桶 - PostgreSQL 支持
NULLS LAST，SQL Server 得用ORDER BY CASE WHEN x IS NULL THEN 1 ELSE 0 END, x DESC - 执行计划里查不到
WindowAgg节点？说明NTILE被退化成嵌套循环，得检查是否加了不当过滤或 JOIN
真正难的是想清楚“要按全局分桶还是分组内分桶”
很多人写 NTILE(4) OVER (ORDER BY sales) 本意是“全量客户分四档”，却忘了外层 WHERE region = 'CN' 一加，窗口行数就变了，桶号重排——这不是函数失效，是逻辑前提已变。
更隐蔽的问题是混淆 PARTITION BY 场景：加了 PARTITION BY dept_id 就变成“每个部门各自分 4 桶”，而非全公司统一分档。是否需要跨组可比性，必须在写 OVER 子句前确认。
- 如需固定分组再筛选（比如“取全局第 1 桶用户做灰度”），必须用 CTE 先算好
NTILE，再对外层WHERE bucket = 1 - 在
GROUP BY后不能直接用NTILE，它必须出现在最内层 SELECT 或 CTE 中 - 大数据量下，
NTILE必须全排序，没索引的ORDER BY字段在千万级表上极易 OOM，别只盯着语法对不对
