用percent_rank()找前10%客户可能为空或不连续，因结果为(rank-1)/(总行数-1)且并列共享值；ntile(10)更可控但会略超比例；严格按数量取前10%应优先用row_number()+floor(count()0.1)。
用 PERCENT_RANK() 找前10%客户：结果可能为空或不连续
PERCENT_RANK() 返回的是相对排名（0 到 1 之间），定义为 (rank - 1) / (总行数 - 1)。它不保证恰好切出 10% 的客户，尤其当客户数少、订单量集中时，顶部一批客户的 PERCENT_RANK() 可能全为 0 或跳变很大。
实操建议：
- 必须配合
ORDER BY按订单总量降序排列，否则无意义 - 过滤条件写成
PERCENT_RANK() OVER (...) ，注意是 <strong> 而非 <code>（因最小值为 0） - 若总客户数为 97，
PERCENT_RANK 可能只返回 9 行（9/96 ≈ 0.094），不是严格 9.7 → 四舍五入取整的 10 行 - 多个客户订单量相同时，
RANK()和PERCENT_RANK()都会并列，但并列者共享同一百分位值，可能导致“挤占”后续名额
用 NTILE(10) 分桶更可控，但需注意分组逻辑
NTILE(10) 把有序结果平均分成 10 组（编号 1–10），第 1 组就是“前 10%”。但它只是尽量均分，不能保证每组行数完全一致 —— 当总行数不能被 10 整除时，较小编号的桶会多拿 1 行。
实操建议：
- 写法是
NTILE(10) OVER (ORDER BY total_orders DESC)，别漏掉OVER子句 - 取前 10% 就是
WHERE tile_num = 1，不是（<code>NTILE最小值恒为 1） - 如果客户数为 103，
NTILE(10)会生成 3 个大小为 11 的桶 + 7 个大小为 10 的桶，第 1 桶含 11 行 → 实际占比约 10.68%，略超 - 同订单量客户可能被强行拆到不同桶（
NTILE不保证并列者同组），这是和RANK类函数的本质区别
真正要“订单量最高的前 10% 客户”，优先用 ROW_NUMBER() + 比例计算
当业务要求严格按数量取 top N（比如 1000 个客户中取前 100 个），ROW_NUMBER() 最可靠：先算出目标行数 FLOOR(COUNT(*) * 0.1)，再取排名 ≤ 该值的记录。
实操建议：
- 必须用子查询或 CTE 先聚合客户订单总数：
GROUP BY customer_id - 外层用
ROW_NUMBER() OVER (ORDER BY total_orders DESC)，避免并列干扰排序位置 - 目标数量建议用
FLOOR(0.1 * COUNT(*) OVER ())，而不是硬编码100，确保随数据量自适应 - 若存在大量同订单量客户，
ROW_NUMBER()会任意排序（取决于引擎实现），必要时加次级排序如customer_id保证可重现
性能与兼容性提醒：窗口函数不是所有旧版数据库都支持
PERCENT_RANK() 和 NTILE() 是 SQL:2003 标准，但 MySQL 5.7 及更早不支持窗口函数；SQLite 直到 3.25.0（2018）才支持；PostgreSQL 8.4+、SQL Server 2005+、Oracle 8i+ 均支持。
实操建议：
- 确认数据库版本：MySQL 用户请升级至 8.0+，否则只能用变量模拟或应用层分页
- 大数据量下，
NTILE和PERCENT_RANK都需全量排序，性能瓶颈和ORDER BY一致，务必在total_orders字段建索引 - 如果表里没有预聚合的订单量字段，
SUM() OVER (PARTITION BY customer_id)比子查询关联更高效，但要注意是否需要去重（如一个客户多地址）
实际业务中，“前10%”这个说法常被当作模糊指标使用，但一旦涉及奖励发放、资源倾斜等场景，就必须明确：是要“比例近似”（选 NTILE）、“相对位置”（选 PERCENT_RANK），还是“确定数量”（选 ROW_NUMBER + 计算）。三者语义不同，混用会导致结果偏差，且这种偏差在客户量小时特别明显。
