exp(log())组合能算乘积，因为log(a×b)=log(a)+log(b)，再通过exp还原得exp(log(a)+log(b))=a×b；需确保底数匹配（如自然对数配exp）、所有值严格大于0。
EXP(LOG()) 组合为什么能算乘积
因为对数把乘法转成加法：LOG(a * b) = LOG(a) + LOG(b)，再用 EXP() 反推回来：EXP(LOG(a) + LOG(b)) = a * b。所以只要对每行取 LOG()、SUM() 后 EXP()，就等价于所有值相乘。
但必须注意：数据库里 LOG() 默认是自然对数（底数 e），和 EXP() 匹配；有些系统（如 SQL Server）LOG() 是以 10 为底，得改用 LOG10() + POWER(10, ...)，否则结果错误。
- MySQL / PostgreSQL / Oracle：直接用
EXP(SUM(LOG(column))) - SQL Server：必须用
POWER(10.0, SUM(LOG10(column)))或EXP(SUM(LOG(column)))（后者要求列值 > 0 且启用LOG()自然对数行为） - 所有系统都要求列值严格大于 0；含 0 或负数会报错或返回 NULL
处理 0 和负数的现实方案
真实数据常含 0、负数甚至 NULL。LOG(0) 是未定义的，LOG(负数) 在实数域无解，直接套用 EXP(SUM(LOG())) 会中断查询。
- 跳过 0 和负数？不行——乘积含 0 就是 0，含奇数个负数结果为负，这是业务逻辑的一部分
- 稳妥做法：先统计符号和零值数量，再对正数子集计算
EXP(SUM(LOG())) - 示例（PostgreSQL）：
SELECT CASE WHEN COUNT(*) FILTER (WHERE val = 0) > 0 THEN 0.0 WHEN COUNT(*) FILTER (WHERE val
性能与精度陷阱
这个技巧在小数据量下没问题，但大数据集上容易出问题：
- 浮点累积误差：
LOG和EXP都是浮点运算，SUM 过程中误差放大，尤其当值跨度大（比如同时有 1e-5 和 1e5）时，结果可能偏差 1% 以上 - 溢出风险：如果乘积理论值超过
DOUBLE表示范围（约 1e308），EXP(SUM(LOG()))会直接返回Infinity或报错，而你可能根本没意识到 - 比原生聚合慢：多数现代数据库（如 PostgreSQL 14+）已支持
PRODUCT()聚合（需扩展），或可用ARRAY_AGG()+ 自定义函数替代，反而更稳
替代方案推荐：别硬套 EXP/LOG
除非你在老版本 MySQL（
- MySQL 8.0.29+：直接用
PRODUCT(column)窗口/聚合函数 - PostgreSQL：安装
tablefunc扩展后可用product()，或用numeric类型配合array_agg()+reduce()（v14+） - 通用兜底：用应用层读取后计算（Python/Go 等），控制精度、异常分支和超大数（如 Python 的
math.prod()或decimal）
EXP/LOG 乘积法是个巧妙的数学 trick，但不是银弹——它把数值稳定性、边界判断和数据库差异全堆在一条 SQL 里，出问题时很难定位。真正上线前，务必用实际数据范围做误差和溢出验证。
