客单价定义为总实收金额除以有效付费订单数，需先筛选已支付且未退款订单，再通过子查询按订单聚合实收金额，最后用SUM/NULLIF(COUNT,0)安全计算，避免AVG误用、NULL及除零错误。

客单价的定义和SQL计算逻辑 客单价 = 总销售额 ÷ 付费订单数，不是总订单数，也不是去重用户数。常见错误是直接用 COUNT(*) 算所有订单行，但未过滤退款、取消或测试订单；或用 COUNT(DISTINCT user_id) 当成交用户数，忽略了同一用户多笔有效订单的情况。

• 必须先筛选出「已支付且未退款」的订单，通常依赖状态字段如 order_status IN ('paid', 'shipped') 或 refund_amount = 0
• 销售额应使用实际实收金额（actual_paid_amount），而非标价（original_amount）
• 订单粒度聚合，不是商品粒度：一张订单含多件商品，只计1次订单

用 AVG() 直接计算的陷阱 很多人写 SELECT AVG(actual_paid_amount) FROM orders WHERE ...，这算的是「每单平均实收金额」，表面看像客单价，但逻辑错位：它把订单当成了“样本”，而客单价本质是「总实收 / 有效订单数」，二者数学等价仅当每单只有一行记录且无重复——但订单表若按商品拆分（即一个订单多行），AVG() 就会严重高估。

• 若订单明细表（order_items）参与聚合，必须先按 order_id 汇总再计算，否则会重复计单
• 正确做法是两层聚合：外层用 SUM() / COUNT()，内层确保每单只贡献一次金额
• 示例（安全写法）：

  SELECT 
  SUM(order_amount) / COUNT(*) AS avg_order_value
  FROM (
  SELECT order_id, SUM(actual_paid_amount) AS order_amount
  FROM order_items
  WHERE order_id IN (
    SELECT order_id FROM orders 
    WHERE order_status IN ('paid', 'shipped') AND refund_amount = 0
  )
  GROUP BY order_id
  ) t;

如何避免NULL和除零错误 当某段时间没有有效订单时，COUNT(*) 为 0，直接除会导致数据库报错（如 PostgreSQL 抛 division by zero）或返回 NULL（MySQL 默认行为）。生产环境必须防御。

• 用 NULLIF(COUNT(*), 0) 包裹分母，使除零转为 NULL，再用 COALESCE(..., 0) 统一兜底
• 不要依赖 WHERE 过滤后“一定有数据”——时间范围可能跨空档期
• 示例修正：

  SELECT 
  COALESCE(SUM(order_amount) / NULLIF(COUNT(*), 0), 0) AS avg_order_value
  FROM (...same subquery as above...);

• 注意：COALESCE 返回数值类型需与分子一致，避免隐式转换导致精度丢失（如整数除整数得整数）

性能关键点：索引与物化建议 大表上反复执行该聚合易慢，尤其订单量超千万时。核心瓶颈常在子查询中的 GROUP BY order_id 和外层关联。

• 必须在 orders 表上为 (order_status, refund_amount) 建联合索引，加速初始过滤
• 若高频查询固定时间窗口（如近30天），考虑预聚合到日级汇总表，字段包括 stat_date、paid_order_cnt、total_paid_amount
• 避免在 WHERE 中对时间字段用函数（如 DATE(created_at)），改用范围查询：created_at >= '2024-01-01' AND created_at

真实场景中，订单状态判定逻辑往往比示例复杂（比如涉及多个状态机、异步更新延迟），务必确认「有效订单」定义与业务方对齐——这点比写对SQL更难，也更容易被忽略。