ntile按排序后行序将结果集均分为n桶，编号从1开始，余数行优先分配给前桶；必须配合order by使用，不按值分布而按行位置切分，各桶行数差不超过1。
NTILE 函数到底怎么分桶？
NTILE 不是按值大小切分区间，而是把结果集**按行数均等分组**。比如 NTILE(4) 会把查询出来的所有行从上到下顺序编号，强行分成 4 个桶，每个桶尽可能包含相同行数（余数行从第 1 桶开始逐个补上）。
常见误解是把它当 PERCENT_RANK 或 CASE WHEN value BETWEEN ... 用——它不看字段值分布，只看排序后的行序。
- 必须配合
ORDER BY使用，否则语法报错：Window function ntiled requires an ORDER BY clause - 如果总行数不能被桶数整除（如 10 行分 4 桶），NTILE 会优先让前面的桶多 1 行：分配为 3,3,2,2
- 重复值在
ORDER BY中位置不确定时（比如多个score = 85），NTILE 分配可能每次运行结果不同——除非加确定性排序，如ORDER BY score, id
为什么 NTILE 分桶结果看起来“不均匀”？
因为它是按行分，不是按值分。例如对销售额排序后跑 NTILE(3)，可能出现第 1 桶最高销额 90 万，第 2 桶最高才 45 万——只因前三分之一行恰好集中了头部客户。
这种“不均匀”不是 bug，是设计使然。如果你要按实际数值区间分桶（比如每 10 万一段），该用 FLOOR(value / 100000) 或 WIDTH_BUCKET（Oracle/PostgreSQL），而不是 NTILE。
一款AI音频处理工具，主要用于MiniMax统一媒体生成技能，用于TokenPlan工作流。当用户要求生成音频、语音、TTS、旁白、图片、插图、姿势等媒体内容时使用，适合需要提升相关任务效率的用户。
- NTILE 适合场景：给用户按活跃度排名后平均分四组做 A/B 测试、给销售员按业绩排序后分档发激励
- 不适合场景：按价格区间归类商品、按分数段统计及格率
- 验证是否真“均分”：查
COUNT(*) GROUP BY ntiled_bucket，看各桶行数差是否 ≤ 1
NTILE 在不同数据库里的行为差异
SQL 标准定义明确，但实现细节仍有坑。MySQL 8.0+ 和 PostgreSQL 完全兼容；SQL Server 也一致；但 SQLite 目前不支持窗口函数，直接报错 no such function: NTILE。
- PostgreSQL 中
NTILE(0)报错：ntile argument must be greater than zero - SQL Server 允许
NTILE与PARTITION BY连用，比如按部门分别做四分位：NTILE(4) OVER (PARTITION BY dept_id ORDER BY salary) - MySQL 8.0.2+ 支持，但旧版本（如 5.7）完全不可用——别在迁移脚本里默认它存在
一个实用例子：给订单按时间分 7 个“周桶”
不是按自然周，而是把全部订单按 created_at 排序后，强行切成 7 组，每组约 1/7 的订单量，用于观察处理延迟趋势。
SELECT order_id, created_at, NTILE(7) OVER (ORDER BY created_at) AS week_bucket FROM orders WHERE status = 'completed';
注意这里没用 DATE_SUB 或 WEEK()，因为目标不是日历周，而是取样均衡性。如果某天订单暴增，那一“桶”里就会集中很多同一天的记录——这正是 NTILE 的预期行为。
真正容易被忽略的是：一旦加了 WHERE 条件，NTILE 就只在过滤后的结果上分桶。别指望它对全表生效后再筛选——窗口函数永远作用于最终结果集。
