如何在SQL Server 2022存储过程中使用近似百分位数函数？-SQL-PHP中文网

approx_percentile_cont 和 approx_percentile_disc 是 sql server 2022 引入的近似百分位聚合函数，基于 t-digest 算法，支持误差约 ±1.33%，需 group by 或聚合上下文使用，不可直接赋值变量。

如何在sql server 2022存储过程中使用近似百分位数函数？

APPROX_PERCENTILE_CONT 和 APPROX_PERCENTILE_DISC 可以直接在存储过程中使用，但必须满足 SQL Server 2022（16.x）或更高版本、数据库兼容级别 ≥ 160，且不能嵌套在子查询或视图定义中直接作为标量表达式调用——它们是聚合函数，需配合 GROUP BY 或作为窗口函数的替代方案用于分组统计。

必须用 GROUP BY 或聚合上下文才能运行

这两个函数不是标量函数，不能像 GETDATE() 那样直接赋值给变量。常见错误是写成：

DECLARE @p95 DECIMAL(10,2) = APPROX_PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY amount);

这会报错 Msg 102, Level 15, State 1: Incorrect syntax near 'WITHIN'，因为缺少聚合上下文。正确做法是：

在 SELECT 中与 GROUP BY 一起使用（例如按地区统计各区域的近似 P95）
或用子查询 + TOP 1 包裹（仅适用于单一分组，如全表整体估算）
不能出现在 WHERE、HAVING 或计算列定义中

APPROX_PERCENTILE_CONT vs APPROX_PERCENTILE_DISC 的参数差异

两者语法完全一致，但语义和适用场景不同：

APPROX_PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY value ASC)：返回插值结果，比如数据是 [100, 200, 300]，P95 可能算出 287.4 —— 不要求该值真实存在，适合平滑离群值影响
APPROX_PERCENTILE_DISC(0.95) WITHIN GROUP (ORDER BY value ASC)：强制返回原始数据中的某个实际值（如 300），更符合业务“取最高一档”的直觉，但对长尾分布敏感
两个函数都只接受一个 order_by_expression，不支持多列排序；类型仅限数值型（int、float、money 等），DECIMAL 必须显式转换为 float 避免隐式转换失败

在存储过程中安全获取单个近似百分位值

若你只需要全表的 P90 值（比如设告警阈值），推荐用子查询封装，避免意外多行：

DreamStudio

一款基于Stable Diffusion生态的在线AI图像生成工具，帮助用户通过文字描述创建艺术图像和视觉素材。

下载

DECLARE @p90 FLOAT;
SELECT @p90 = APPROX_PERCENTILE_CONT(0.90) WITHIN GROUP (ORDER BY response_time_ms)
FROM dbo.requests
WHERE status = 'success';

注意点：

必须确保 WHERE 条件后仍有足够数据（空集时返回 NULL，不会报错）
不要加 GROUP BY () —— 虽然语法合法，但 SQL Server 2022 当前版本对空分组的支持不稳定，可能触发不可预期的执行计划退化
如果后续要拿这个值做 JOIN 或过滤，建议先 IS NULL 判断，避免 NULL 传播导致逻辑短路

性能优势明显，但误差边界需被业务接受

实测千万级订单表上，APPROX_PERCENTILE_CONT(0.99) 比 PERCENTILE_CONT(0.99) OVER() 快 5–8 倍，内存占用下降 90%+。不过 t-Digest 算法默认误差约 ±1.33%，意味着真实 P99 可能在 97.67–99.00 之间浮动。如果你的报表需求是“大致反映趋势”，没问题；但如果是金融风控类场景要求严格阈值（如“超 P99.5 才触发人工复核”），仍应坚持用精确函数。

真正容易被忽略的是：这两个函数在 Azure SQL 托管实例和 Fabric Warehouse 中行为一致，但在旧版兼容模式（如 150）下会直接不可用——检查 SELECT compatibility_level FROM sys.databases WHERE name = DB_NAME(); 是上线前必做的一步。