如何通过SQL分组查询来提取RFM客户价值模型的特征？

RFM三维度需通过GROUP BY客户ID聚合计算：R用MAX(order_date)转为距今天数，F用COUNT(*)统计订单数，M用SUM(order_amount)汇总净金额；分档打分须动态计算阈值并用CASE WHEN分别处理，拼接用CONCAT避免位数错乱；过滤聚合结果必须用HAVING而非WHERE。

RFM三个维度在SQL里怎么分别计算

RFM的R（最近购买时间）、F（购买频次）、M（消费金额）不是天然存在的字段，得从订单表里算出来。核心是用 GROUP BY 按客户ID聚合，再配合聚合函数和日期函数提取特征。

常见错误是直接对原始订单表 SELECT 不加 GROUP BY，或者把 MAX(order_date) 和 COUNT(*) 放在没分组的查询里，报错 ERROR 1140: In aggregated query without GROUP BY。

• R：用 MAX(order_date) 得到每个客户的最后下单时间；注意字段类型要是 DATE 或 DATETIME，否则 MAX() 可能返回字符串最大值
• F：用 COUNT(*) 统计订单条数；如果一张订单含多商品，别误用 COUNT(product_id) —— 那会重复计数
• M：用 SUM(order_amount) 汇总实付金额；确认该字段不含退款、优惠券抵扣等干扰项，否则要先过滤或用净金额字段

如何把R转换成可打分的“天数”数值

原始 MAX(order_date) 是日期，但RFM打分需要数值型“距今多少天”，得用日期差函数转换。不同数据库语法差异大，容易踩坑。

MySQL用 DATEDIFF(CURDATE(), MAX(order_date))；PostgreSQL用 CURRENT_DATE - MAX(order_date)（结果自动为整数天）；SQLite用 julianday('now') - julianday(MAX(order_date))。别用 NOW() - order_date 这类非法表达式。

• 必须确保 order_date 非空，否则 MAX() 返回 NULL，导致整个差值为 NULL
• 如果业务中存在未来订单（如预售），DATEDIFF 可能返回负数，打分逻辑需前置处理：NULLIF(GREATEST(0, DATEDIFF(...)), 0)
• 不要在 WHERE 里用这个计算字段筛选——它只能出现在 SELECT 或 HAVING，否则报错 Unknown column in WHERE clause

分组后怎么统一打分并拼成RFM组合

SQL本身不内置RFM分箱逻辑，得靠条件表达式手动实现。常见做法是用 CASE WHEN 对每个维度单独分5档（1–5分），再拼接成三位数（如 543）。

关键点在于分档阈值必须基于当前数据分布动态计算，不能写死。比如R越小越好，所以“近30天”打5分、“31–60天”打4分；而F和M是越大越好，得先用子查询或CTE算出各分位数。

• 推荐用窗口函数预计算分位点：PERCENTILE_CONT(0.8) WITHIN GROUP (ORDER BY recency_days)（PostgreSQL/Oracle），MySQL 8.0+ 可用 PERCENT_RANK() 代替
• 避免在同一个 CASE 里混用R/F/M的排序方向（R升序打分、F/M降序打分），容易逻辑反了；建议分开写三段 CASE 再 CONCAT()
• 拼接时用 CONCAT(r_score, f_score, m_score)，别用 r_score * 100 + f_score * 10 + m_score —— 当某维度是0分时（极少见但可能），会导致位数错乱

为什么GROUP BY后加HAVING比WHERE更安全

RFM建模常需过滤“无效客户”，比如只保留至少下过2单、总金额超100元的客户。这类条件依赖聚合结果（COUNT(*) >= 2），必须用 HAVING，而不是 WHERE。

典型错误是写成 WHERE COUNT(*) >= 2，直接报错 Invalid use of group function。因为 WHERE 在分组前执行，根本看不到聚合值。

• HAVING 是唯一能引用 COUNT/SUM/MAX 等聚合结果的地方
• 如果还要结合原始字段过滤（如 WHERE order_status = 'paid'），务必放在 HAVING 前面——先筛有效订单，再聚合，最后用 HAVING 控制客户准入
• 性能上，HAVING 无法利用索引，大数据量时建议先用 WHERE 尽量缩小数据集，再分组

真正麻烦的是R、F、M三者分布极度偏态（比如90%客户M=0），分档边界稍有偏差，就会让大量客户挤在同一个RFM组合里。这事得在SQL跑完后，用业务规则人工校验几个典型样本，不能全信自动分箱结果。