多数主流sql引擎无内置product()函数，需用exp(sum(ln(x)))绕过，但要求x>0；含0或负数时须分类处理零值计数与符号位，且结果为浮点近似，非精确整数。
为什么不能直接用 PRODUCT() 函数
多数主流 SQL 引擎（如 PostgreSQL、SQL Server、SQLite）压根没有内置的 PRODUCT() 聚合函数。MySQL 8.0+ 虽然有 GROUP_CONCAT() 可拼接后用应用层计算，但不解决原生聚合需求。硬写循环或自定义函数又受限于权限和维护成本——所以得靠数学恒等式绕过：
EXP(SUM(LN(x))) = x₁ × x₂ × … × xₙ，前提是所有 x > 0。
如何安全处理零值和负数
一旦字段含 0，LN(0) 直接报错（NaN 或 NULL）；含负数时 LN() 在实数域无定义。必须提前过滤或分类处理：
- 若业务允许忽略零值：
WHERE x != 0（但注意：全为零时结果应为0，此法会返回NULL） - 若需保留零值语义：先统计零值个数，
COUNT(CASE WHEN x = 0 THEN 1 END) > 0则整个分组乘积为0 - 若含负数：拆出符号位，用
SUM(CASE WHEN x 判断最终符号，再对 <code>ABS(x)做EXP(SUM(LN(ABS(x))))
PostgreSQL 和 MySQL 的写法差异
两者都支持 LN() 和 EXP()，但 NULL 处理和类型隐式转换细节不同：
- PostgreSQL：
LN(NULL)返回NULL，整组含NULL时SUM()结果为NULL，最终EXP(NULL)还是NULL；建议加WHERE x IS NOT NULL AND x > 0 - MySQL：
LN(0)返回-inf，EXP(-inf)是0，看似“能跑”，但实际不可靠（-inf参与SUM可能溢出或触发 warning）；必须显式排除非正数 - 示例（PostgreSQL，安全版）：
SELECT group_id, CASE WHEN COUNT(CASE WHEN val = 0 THEN 1 END) > 0 THEN 0.0 WHEN COUNT(CASE WHEN val
性能与精度陷阱
这个技巧本质是浮点运算链：取对数 → 求和 → 指数还原。小数据看不出问题，但大数值或大量小数相乘时容易失真：
- 例如
0.1 * 0.1 * 0.1理论是0.001，但EXP(SUM(LN(0.1)))可能算出0.0010000000000000002 - 超大整数（如 > 1e15）经
LN()后精度进一步损失，还原后可能偏差整数位 - 替代思路：如果只是计数类乘积（比如概率连乘），优先考虑改用对数域直接运算，避免还原；如果是精确整数场景，不如在应用层用 Python/Java 的高精度库批量处理
真正要小心的不是公式本身，而是没意识到它把「精确乘法」悄悄换成了「浮点近似」——尤其当结果要进报表或做条件判断时，这点误差可能被放大。
