错误做法是直接用 group by user_id having max(last_active_time)

直接用 GROUP BY user_id 算最后活跃时间，再 HAVING MAX(last_active_time) 是错的——它漏掉所有没行为记录的用户，也混淆了“从未活跃”和“沉默”的区别。

先从行为日志里算出每个用户的最后活跃时间

沉默用户必须基于“有历史行为但近期无动作”来定义，所以不能依赖现成的 last_active_time 字段（多数表根本没存）。得从原始行为表聚合出来：

• MAX(action_time) 比子查询 + ORDER BY ... LIMIT 1 更可靠，后者在同时间多条记录时可能随机丢数据
• 如果用户只有注册没其他行为，而注册时间在 users.created_at，就得用 UNION ALL 合并两表再 GROUP BY，不能只查行为表
• MySQL 8.0+ 可用 COALESCE(MAX(action_time), created_at) 兜底，但低版本必须先 LEFT JOIN users 再处理 NULL
• 字段是 TIMESTAMP 且数据库时区为 UTC，而业务按北京时间判断沉默，得先 CONVERT_TZ(action_time, '+00:00', '+08:00') 再比较

用日期差构造“沉默区间分组键”

单纯筛选出 last_active_time 只能知道“是否沉默”，无法按“沉默了多久”分组。要统计“沉默 7–14 天”“沉默 15–30 天”这类区间，得把沉默时长转成可分组的标识：

• 用 DATE_SUB(CURDATE(), INTERVAL 1 DAY) 得到昨天，再减去 last_active_time，得到整数天数：CURDATE() - INTERVAL 1 DAY - last_active_time（MySQL）或 (CURRENT_DATE - '1 day'::INTERVAL - last_active_time)::int（PostgreSQL）
• 别用 BETWEEN 划分区间，改用 CASE WHEN 避免边界重叠：比如 WHEN silence_days >= 7 AND silence_days
• 若 last_active_time 是 DATETIME，先 CAST(last_active_time AS DATE)，否则跨午夜计算会虚增一天
• 注意 CURDATE() 返回的是本地时区日期；如果行为时间存的是 UTC，必须统一转换后再相减

WHERE 过滤必须放在最外层或子查询中

错误写法是 GROUP BY user_id HAVING MAX(action_time) ——这会导致全表扫描，且逻辑上找的是“最后活跃在 8 月 1 日前”的用户，不是“8 月 1 日至今无行为”的用户。

• 正确做法是：先用 WHERE action_time >= '2026-07-01' 限定时间窗口（比如查最近 30 天），再聚合；否则没索引支撑的 MAX() 会扫全表
• 如果行为表极大，且只关心最近活跃用户，加 WHERE action_time >= DATE_SUB(CURDATE(), INTERVAL 90 DAY) 能减少 90% 以上扫描行数
• 联合索引 INDEX(user_id, action_time) 对 PARTITION BY user_id ORDER BY action_time 和 MAX() 都有效；单列索引效果差
• 别在 WHERE 里对 action_time 用函数（如 DATE(action_time)），会失效索引

真正容易被忽略的是：沉默区间分组依赖于“最后活跃时间”的准确性，而这个时间本身可能来自不同表、不同字段、不同时区，甚至包含 NULL 或非法值（如 '0000-00-00'）——没做预清洗就直接分组，结果偏差会逐级放大。