EXP和LN在增长率计算中通过“取对数→线性运算→指数还原”实现稳定连乘：LN将各期(1+r)的乘法转化为加法，EXP再将和还原为总增长倍数，避免浮点溢出与精度损失。
EXP 和 LN 在增长率计算中到底起什么作用
EXP 和 LN 是互为反函数的数学函数，不是专门用来算增长率的，但它们能帮你在对数尺度上做加减运算，再还原回原始尺度——这比直接用幂运算更稳定，尤其处理长期复利或跨量级数据时。比如年化增长率 5%，连续 3 年，EXP(LN(1.05) * 3) 比 POWER(1.05, 3) 在浮点精度和 NULL 处理上更可控。
用 LN 把乘法转成加法，再用 EXP 还原结果
复合增长率本质是多个期增长率连乘：(1+r₁) × (1+r₂) × … × (1+rₙ)。直接连乘容易溢出或受小数精度影响；而取自然对数后变成求和：LN(1+r₁) + LN(1+r₂) + ... + LN(1+rₙ)，最后用 EXP(SUM(...)) 还原。
- 必须确保每期增长率
r满足1 + r > 0，否则LN(1 + r)报错（如 PostgreSQL 抛invalid argument for ln()，MySQL 返回NULL） - SQL 中要先过滤掉
r 的异常记录，或用 <code>CASE WHEN替换为默认值（如LN(COALESCE(NULLIF(1 + r, 0), 1))） - 注意：有些数据库（如 SQLite）不支持
LN，需用LOG(x)（默认自然对数），而 SQL Server 用LOG(x)，Oracle 用LN(x)
实际计算年化复合增长率（CAGR）的写法
给定起始值 start_value、期末值 end_value、期数 n_periods，标准 CAGR 公式是 (end_value / start_value)^(1/n) - 1。用 EXP/LN 改写可避免幂函数在 n 很大或很小时的数值不稳定：
SELECT EXP(LN(end_value / start_value) / n_periods) - 1 AS cagr FROM your_table;
关键点：
-
end_value / start_value必须 > 0，否则LN失败；建议前置检查：WHERE end_value > 0 AND start_value > 0 - 如果
n_periods是整数天数，但你想算年化，记得除以 365.25（或按业务规则用 360/365） - PostgreSQL 中若字段为
NUMERIC，LN仍可工作；但 SQLite 的LOG对整数输入可能隐式转为浮点，要注意精度截断
遇到 NULL 或负增长时怎么安全兜底
真实业务数据常有缺失或负向变动，硬套 EXP(LN(...)) 会中断整个聚合。稳妥做法是把逻辑拆开，显式控制空值与边界：
SELECT
CASE
WHEN MIN(1 + growth_rate) <= 0 THEN NULL
ELSE EXP(AVG(LN(1 + growth_rate))) - 1
END AS avg_compound_growth
FROM your_data
WHERE growth_rate IS NOT NULL;这里用了 AVG(LN(...)) 而非 SUM，是因为它等价于几何平均的对数形式，更适合表达“典型单期复合率”。但要注意：
-
AVG(LN(1 + r))要求所有r都有效，所以 WHERE 过滤不能漏 - 某些场景（如月度环比）需要先用
LAG()算出各期r，此时窗口函数和LN嵌套容易因排序错位引入错误，务必确认PARTITION BY和ORDER BY正确 - Oracle 中
LN对0返回报错，但对NULL返回NULL；而 MySQL 的LN(0)返回-inf，再进EXP可能得0，行为不一致
真正麻烦的从来不是公式本身，而是不同数据库对边界值的静默处理方式——测试时一定要用含 0、负数、NULL 的小数据集跑一遍 LN 和 EXP 组合。
