ntile(n)按行数均分而非数值均等，各桶行数至多相差1；需用floor(total/n)和total%n预判分布，order by须加唯一列防重复值乱序，null需显式处理，where过滤须在cte中完成，跨库需注意兼容性，分层前必须聚合。
NTILE() 的“平均”是行数切分，不是数值均等
NTILE(n) 从不承诺每桶行数相等，它只保证各桶行数相差不超过 1。这是 SQL 标准定义的行为，不是实现缺陷。它的逻辑是：先按 ORDER BY 排序得到完整行序列，再从上到下依次编号、切块。
例如总行数为 103、NTILE(10)：103 ÷ 10 = 10 余 3 → 前 3 个桶各 11 行，后 7 个桶各 10 行。你看到第 1 桶比第 10 桶多一行，不是写错了，而是设计如此。
常见误操作是拿 COUNT(*) 分组后对比，发现“不匀”就怀疑语法或数据问题。其实只要算清 FLOOR(total / n) 和 total % n，就能预判分布。
ORDER BY 不稳定导致同一值被拆进不同桶
当排序字段存在大量重复值（比如 50 万条 status = 'pending'），又没加唯一列兜底，数据库每次执行可能以不同物理顺序排列这些行，NTILE() 就会把它们随机分到不同桶里——这不是函数出错，是排序本身不确定。
- 必须加固
ORDER BY：在业务字段后追加唯一列，如ORDER BY amount DESC, order_id - NULL 值默认排序行为因库而异（SQL Server 排最前，PostgreSQL 可用
NULLS LAST），建议显式处理，如ORDER BY COALESCE(amount, -1) DESC - 避免用表达式排序（如
ORDER BY UPPER(name)），否则无法走索引，大表易触发磁盘排序
WHERE 过滤位置错误会让分桶“失效”
NTILE() 是窗口函数，计算发生在逻辑查询的早期阶段。如果你写成：
SELECT * FROM t WHERE NTILE(4) OVER (ORDER BY x) = 1;
这语法根本通不过；而写成：
SELECT * FROM t WHERE bucket = 1;
其中 bucket 是外层 SELECT 中定义的别名，那实际执行是：先对全表算桶号 → 再过滤 → 最终第 1 桶的行数可能远少于预期（尤其原始数据含大量 NULL 或低值被 WHERE 干掉时）。
正确做法是用 CTE 或子查询固化结果：
WITH ranked AS (SELECT *, NTILE(4) OVER (ORDER BY sales DESC) AS bucket FROM t) SELECT * FROM ranked WHERE bucket = 1;
跨库兼容性和聚合前提常被忽略
MySQL 5.7 及更早版本不支持 NTILE()，直接报错 FUNCTION xxx.NTILE does not exist；SQLite 完全不支持，只能手写模拟：(ROW_NUMBER() OVER (ORDER BY x) - 1) / CAST((SELECT COUNT(*) FROM t) AS INTEGER) + 1，但整数除法行为因引擎而异。
另一个高频陷阱：没聚合就直接对明细表跑 NTILE()。比如对订单表 orders 执行 NTILE(4) OVER (ORDER BY amount)，分的是“订单”，不是“用户”。一个高价值用户有 20 笔订单，就会被拆进 20 行、打散到多个桶——分层完全失真。
真正做用户分层，必须三步闭环：
- 先聚合（如
GROUP BY user_id算出SUM(amount)） - 再排序（
ORDER BY total_amount DESC） - 最后分桶（
NTILE(4) OVER (ORDER BY total_amount DESC)）
最容易被跳过的其实是第一步：聚合前的行数 ≠ 业务实体数，这时候谈“均匀分层”没有意义。
