NTILE()按行数均分数据而非数值区间，适用于快速探查分布形状；需配合ORDER BY使用，返回整数标签，总行数不能被N整除时小编号组多一行。
怎么用 NTILE() 做等宽分段频次统计
直接说结论：如果想把数值字段（比如销售额、年龄）平均切成 N 组，再统计每组记录数，NTILE() 是最省事的窗口函数。但它不按真实数值区间切，而是按行数均分——100 条记录用 NTILE(4)，就是强行分成 4 组，每组约 25 行，不管这 25 行的值跨度有多大。
常见错误是以为 NTILE(4) 会自动按 [0–25), [25–50), … 切数值范围，结果发现分组边界和业务理解完全对不上。
- 适用场景：快速探查数据分布“形状”，比如看用户消费金额大致分几档，不要求边界精确
- 必须配合
ORDER BY使用，否则报错；顺序决定分组依据（升序/降序影响低值高值在哪组） -
NTILE()返回的是整数标签（1, 2, 3…），不是区间描述，后续要GROUP BY才能算频次 - 当总行数不能被 N 整除时，较小编号的组会多一行（例如 101 行分 4 组 → 第1组26行，其余25行）
示例：按订单金额四分位分组并计数
SELECT ntile_group, COUNT(*) AS cnt FROM ( SELECT NTILE(4) OVER (ORDER BY amount) AS ntile_group FROM orders ) t GROUP BY ntile_group ORDER BY ntile_group;
用 CASE WHEN + 数值边界做精准分段频次
真正需要按固定数值区间（比如 0–99, 100–199, 200+）统计频次，NTILE() 就不合适了——得手动定义边界，用 CASE WHEN 分类后再聚合。
容易踩的坑是边界重叠或遗漏，尤其是开闭区间没写清楚，导致某条记录没进任何组，或者进了两个组。
- 所有分支必须覆盖全集，建议末尾加
ELSE 'other'检查异常值 - 数值比较用
和 <code> 要统一，避免像 <code>BETWEEN那样隐含闭区间带来的混淆 - 如果字段可能为
NULL，CASE不会匹配任何分支，需显式处理WHEN amount IS NULL - 性能上无明显瓶颈，但边界太多（如 20 段）会让 SQL 可读性骤降，可考虑先建临时映射表
示例：按金额分三档统计
SELECT
CASE
WHEN amount < 100 THEN 'low'
WHEN amount < 500 THEN 'mid'
ELSE 'high'
END AS amount_level,
COUNT(*) AS cnt
FROM orders
GROUP BY 1
ORDER BY 1;
WIDTH_BUCKET() —— Oracle/PostgreSQL 里更接近“直方图”的解法
如果你用的是 PostgreSQL 或 Oracle，WIDTH_BUCKET() 是比 NTILE() 更贴近“数值分段”本意的函数：它接受最小值、最大值、桶数，自动算出等宽区间，并把每个值归入对应桶号（从 1 开始）。
注意它不处理超出边界的值——默认把小于下界归为 0，大于上界归为 n+1，这点常被忽略，导致频次统计少算或多算。
- 必须显式传入 min/max，不能用列聚合结果动态推导（除非嵌套子查询）
- PostgreSQL 中返回
int，Oracle 中返回number，但都可直接用于GROUP BY - 和
NTILE()最大区别：相同数值一定进同一桶；而NTILE()只看排序位置，相同值可能因排序稳定性被拆到不同组 - MySQL 没原生支持，得用
FLOOR((value - min) / width)手动模拟，但要注意浮点误差和越界
示例（PostgreSQL）：将金额 0–1000 等分为 5 桶
SELECT WIDTH_BUCKET(amount, 0, 1000, 5) AS bucket, COUNT(*) AS cnt FROM orders GROUP BY 1 ORDER BY 1;
为什么不用 HISTOGRAM() 或其他“自动分箱”函数
MySQL 8.0+ 有 HISTOGRAM（仅用于 ANALYZE TABLE 的统计信息收集），不是 SQL 运行时函数；SQL Server 没内置直方图函数；SQLite 也没有。所谓“数据库自动生成分段”基本不存在于标准查询层面。
这意味着只要需求是“运行时按数值区间分组并统计”，你就得自己控制边界逻辑——无论是硬编码 CASE、用 WIDTH_BUCKET() 算桶，还是先查出 min/max 再拼 SQL。
- 别依赖执行计划里的“直方图估算”，那只是优化器用的粗略统计，不可用于业务输出
- 如果分段规则经常变（比如每月调整金额阈值），建议把边界存在配置表里，用 JOIN 替代硬编码
- 浮点数做区间判断时，优先用
而非 <code> 避免边界值因精度问题漂移
边界定义这件事，数据库不会替你做判断，哪怕函数名字听起来很智能。
