不能直接用AVG()计算几何平均数，因其本质是算术平均；须用EXP(AVG(LOG(x)))转换，且要求所有x>0。
为什么不能直接用 AVG() 计算几何平均数
几何平均数要求对所有正数取乘积后再开 n 次方，而 SQL 的 AVG() 是算术平均（求和除以数量），两者数学定义完全不同。直接 AVG(x) 会严重高估真实几何均值，尤其在数据跨度大、含离散峰值时——比如 [1, 1, 1, 100] 的几何平均是 ≈3.16，算术平均却是 25.75。
核心难点在于：SQL 标准不提供 GEOMEAN() 聚合函数（PostgreSQL 14+ 有 geometric_mean() 扩展，但 MySQL、SQL Server、旧版 PostgreSQL 均无）。必须靠对数恒等式转换：GEOMEAN(x₁,x₂,…,xₙ) = EXP(SUM(LN(xᵢ)) / n)
注意前提：所有 xᵢ 必须严格 > 0；LN(0) 或 LN(负数) 会报错或返回 NULL，导致整组结果失效。
MySQL / PostgreSQL / SQL Server 中通用写法
各数据库对对数函数命名略有差异，但逻辑一致：先过滤非正数 → 取自然对数 → 求和 → 除以计数 → 指数还原。
- MySQL：用
LOG()（默认自然对数），EXP() - PostgreSQL：用
LN()或LOG()（LOG()在 PG 中也指自然对数），EXP() - SQL Server：用
LOG()（自然对数），EXP()
示例（按 category 分组）：
SELECT category, EXP(AVG(LOG(value))) AS geomean FROM metrics WHERE value > 0 GROUP BY category;
关键点：
• 必须用 AVG(LOG(value))，而非 SUM(LOG(value))/COUNT(*) —— 因为 AVG() 自动忽略 NULL，而 WHERE value > 0 已确保输入有效，二者等价但 AVG() 更简洁；
• 若某组存在 value 且未加 <code>WHERE 过滤，LOG() 返回 NULL，AVG() 会跳过它，但该组实际几何平均无定义，应显式排除；
• 浮点精度误差不可避免，结果可能带微小尾差（如 3.000000000000001），必要时用 ROUND(…, 6) 截断。
处理零值、负数和 NULL 的安全策略
现实数据常含 0、负数或缺失。强行计算会中断查询或返回错误值（如 MySQL 的 Warning: Null value is eliminated by an aggregate，或 PostgreSQL 的 ERROR: cannot take logarithm of zero）。
推荐三步防御：
- 用
WHERE value > 0在聚合前硬过滤（最简单、性能最好） - 若需保留分组结构（即使无有效值），改用条件表达式：
EXP(AVG(CASE WHEN value > 0 THEN LOG(value) END))—— 此时若全组无效，AVG()返回 NULL，不会报错 - 检查是否真有数据参与计算：
COUNT(CASE WHEN value > 0 THEN 1 END)与COUNT(*)对比，可识别脏数据比例
特别注意：某些数据库（如旧版 MySQL）对 LOG(0) 返回 -inf，EXP(-inf) 得 0，造成静默错误。务必验证输入范围。
性能与精度注意事项
对数转换本身开销极小，瓶颈通常在 I/O 和 WHERE 过滤。但有两个易被忽略的细节：
- 索引失效风险：若写成
LOG(value) > 1等条件，无法使用value列索引；应始终把原始列放在 WHERE 左侧，如value > EXP(1) - 浮点下溢：当
value极小（如 1e-300），LOG(value)会下溢为 -inf，再EXP()得 0；此时应加前置判断：WHERE value >= 1e-150 - 分组内样本量过少（n=1）时，几何平均退化为原值，但公式仍成立；n=0 时结果为 NULL，需业务层明确语义（如视为空组）
跨数据库移植时，唯一需调整的是对数函数名；EXP 和 AVG 行为高度一致。真正麻烦的是数据质量——几何平均对异常值鲁棒，但对零/负值零容忍，这比语法更常卡住上线。
