直接SUM(amount)会高估LTV，因含退款、测试单等；应过滤status为paid/shipped/completed，排除测试用户，统一币种，并用范围查询替代函数索引失效。
用 SUM() 直接累加订单金额是最常见也最危险的做法
很多人一上来就写 SELECT user_id, SUM(amount) FROM orders GROUP BY user_id，以为这就得到了用户生命周期总价值（LTV）。但实际中，amount 字段常含退款、测试订单、负向调整单——直接 SUM() 会高估。更关键的是，LTV 本质是“已实现+可归因”的净收入，不是所有订单都该计入。
实操建议：
- 先过滤掉状态异常的记录：
WHERE status IN ('paid', 'shipped', 'completed')，排除'cancelled'、'refunded'、'pending' - 显式排除测试用户：
AND user_id NOT IN (SELECT user_id FROM users WHERE is_test = true) - 若存在多币种，必须先统一换算为基准货币（如 USD），不能直接加总原始
amount - 避免在
WHERE中使用函数（如DATE(created_at) >= '2020-01-01'）导致索引失效；改用范围查询：created_at >= '2020-01-01' AND created_at
需要区分首次付费时间？用 MIN() 和窗口函数组合判断新老客
LTV 常需按“首次付费后 N 个月内”的口径计算，否则老用户历史订单会拉长周期、稀释真实留存影响。这时候不能只靠 GROUP BY user_id，得先锚定每个用户的首笔有效付费时间。
实操建议：
- 用子查询或 CTE 先算出每位用户的首单时间：
MIN(CASE WHEN status = 'paid' THEN created_at END) - 再与原订单表
JOIN，限定只统计「首单后 365 天内」的订单：o.created_at （PostgreSQL）或DATEADD(day, 365, u.first_paid_at)（SQL Server） - MySQL 用户注意：
DATE_ADD()比ADDDATE()更通用，且避免用STR_TO_DATE()在聚合前转换时间字段，性能损耗大
遇到部分订单无用户归属？用 LEFT JOIN + COALESCE() 控制空值行为
订单表里 user_id 为空（比如游客下单、匿名埋点漏传）时，GROUP BY user_id 会把它们全挤进同一组（NULL 组），造成 LTV 统计失真，甚至掩盖数据质量问题。
实操建议：
- 显式排除
user_id IS NULL：这是最干净的做法，前提是业务允许丢弃这部分数据 - 若需保留分析，用
COALESCE(user_id, -1)将空值映射为特殊 ID，但后续报表必须标注“匿名用户合计”，不可混入真实用户 LTV - 更稳妥的是反向验证：对比
COUNT(DISTINCT user_id)和COUNT(*)的比值，若低于 98%，说明归属率异常，应暂停 LTV 报表产出并排查上游埋点或登录态逻辑
千万小心：AVG(SUM()) 不是平均 LTV，而是平均「用户平均值」
有人想算“用户平均 LTV”，顺手写成 SELECT AVG(total_ltv) FROM (SELECT user_id, SUM(amount) AS total_ltv FROM orders ... GROUP BY user_id) t。语法没错，但语义错——这算的是“每个用户 LTV 的算术平均”，完全没考虑用户分层（如 VIP 占比 5% 却贡献 40% 收入）。真正有业务意义的平均 LTV，往往要加权或分位数表达。
实操建议：
- 汇报场景优先用中位数：
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY total_ltv)（PostgreSQL/SQL Server），抗异常值干扰 - 若必须用均值，注明分母是“付费用户数”而非“全部注册用户”，并在 SQL 中显式过滤：
HAVING COUNT(*) > 0（确保至少有一笔有效订单） - 别在应用层拼接多个聚合结果来“模拟加权”，SQL 层用
SUM(amount) / COUNT(DISTINCT user_id)更可靠，且能利用执行引擎优化
真实业务中，LTV 的分母定义（是否含未付费用户）、时间窗口（滚动 12 个月 or 首单起固定周期）、金额口径（是否剔除佣金/支付手续费）才是分歧最大、最容易被 SQL 表面逻辑掩盖的地方。写完聚合语句后，务必拿 3–5 个典型用户的手动对账结果反向验证。
