不能。NTILE(10)是等频分桶，组大小不均，编号为1的桶占比不严格等于10%；精确取前10%应使用ROW_NUMBER()配合COUNT(*) OVER()计算行数上界后筛选。
NTILE(10) 能不能直接拿到前10%？
不能。NTILE(10) 把数据平均分成 10 组，每组编号 1–10，但它是「等频分桶」，不是「按值截断」。如果某组数据量少，比如总共只有 13 行，NTILE(10) 会分配出长度为 2 或 1 的桶（因为 13 ÷ 10 = 1 余 3，前三桶各 2 行，后七桶各 1 行），此时 NTILE(10) = 1 的行数是 2，占比约 15.4%，不是严格 10%。
真正要取「前10%的记录」，核心是：先算总数，再算 10% 对应的行数上界，最后用行号筛选。
用 ROW_NUMBER() + COUNT(*) OVER() 算精确前10%
这是最可靠的做法：先用 COUNT(*) OVER() 得到每组总行数，再用 ROW_NUMBER() OVER (ORDER BY ...) 排序编号，最后保留编号 ≤ 总数 × 0.1 的行。
-
ROUND(COUNT(*) OVER (PARTITION BY category) * 0.1, 0)计算每组应取的行数（四舍五入取整） -
ROW_NUMBER() OVER (PARTITION BY category ORDER BY score DESC)按分数降序编号 - WHERE 条件中比较
rn <= ceiling_cnt，注意用<=不是=
示例（取每类中分数最高的前10%）：
SELECT category, score, name
FROM (
SELECT category, score, name,
ROW_NUMBER() OVER (PARTITION BY category ORDER BY score DESC) AS rn,
CEILING(COUNT(*) OVER (PARTITION BY category) * 0.1) AS ceiling_cnt
FROM sales
) t
WHERE rn <= ceiling_cnt;NTILE(10) 的适用场景和陷阱
NTILE(10) 适合做「粗略分层」或「相对排名归类」，比如“把用户按消费额分为十分位组”，但不适合精确截取 Top 10% 数据。
- 当组内行数不能被 10 整除时，
NTILE(10)会优先让编号小的桶多放 1 行 → 编号为 1 的桶总是最大，可能远超 10% - 排序字段有重复值时，
NTILE仍会强行拆分，导致相同 score 被分到不同桶，破坏业务语义 - 某些数据库（如 MySQL 8.0+）支持
NTILE，但 Hive/Spark SQL 中需确认版本是否支持窗口函数嵌套
性能与兼容性提醒
在大数据量下，ROW_NUMBER() + COUNT(*) OVER() 需要两次扫描（逻辑上），但现代引擎（PostgreSQL、SQL Server、BigQuery）通常能优化成一次遍历；而 NTILE 内部也依赖排序，性能差异不大。
真正容易被忽略的是边界处理：
- 总数为 0 或 1 时，
CEILING(0.1)是 1，但取前 1 行是合理的；若想严格 ≥10% 可改用FLOOR，但会丢失小样本的全部结果 - 排序字段为 NULL 时，不同数据库默认把 NULL 排最前或最后，需显式写
ORDER BY score DESC NULLS LAST（PostgreSQL）或用COALESCE(score, -999999)兜底 - 如果要求「并列不跳号」（即同分同名次），得换用
RANK()，但此时前10%的行数就不可控了
实际用的时候，别迷信 NTILE —— 它名字像百分位，但行为是分段计数器。真要卡比例，老老实实用行号+总数算。
