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跑完后，用业务规则人工校验几个典型样本，不能全信自动分箱结果。
