APPROX_PERCENTILE_CONT 和 APPROX_PERCENTILE_DISC 是 SQL Server 2022 引入的近似百分位聚合函数，基于 t-Digest 算法，支持误差约 ±1.33%，需 GROUP BY 或聚合上下文使用，不可直接赋值变量。
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 值（比如设告警阈值），推荐用子查询封装，避免意外多行：
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(); 是上线前必做的一步。
