直接用GROUP BY + MIN/MAX计算每人首次和末次行为时间，无需JOIN；需确保event_time为DATETIME类型、过滤NULL；关联用户属性时用LEFT JOIN更安全，索引user_id，日期留存分析须在ON中限定目标日期。
用GROUP BY + MIN/MAX直接算首次和末次，别JOIN
首次行为（如first_login）和末次行为（如last_visit）本质是按user_id分组后的极值，不需要JOIN任何表。强行JOIN只会增加中间结果集体积、拖慢查询，还容易因关联逻辑出错引入NULL或重复行。
正确做法就是单表聚合：
-
MIN(event_time)得到每人最早行为时间，对应首次行为日 -
MAX(event_time)得到每人最晚行为时间，对应末次行为日 - 必须确保
event_time是DATETIME或TIMESTAMP类型，否则字符串比较会错（比如'2023-10-01'>'2023-9-30'不成立） - 加
WHERE event_time IS NOT NULL过滤脏数据，避免MIN()/MAX()返回NULL污染结果
示例语句：
SELECT user_id,
MIN(event_time) AS first_event,
MAX(event_time) AS last_event,
COUNT(*) AS total_events
FROM user_events
WHERE event_time IS NOT NULL
GROUP BY user_id;
需要关联用户属性时，LEFT JOIN比INNER JOIN更安全
如果除了行为时间，还要带出用户注册城市、设备类型等维度，得关联users表。这时务必用LEFT JOIN，否则没注册信息的用户（比如只浏览未登录的游客）会被直接丢掉，导致first_event统计失真。
常见错误是写成INNER JOIN users u ON e.user_id = u.user_id，这会隐式过滤掉所有匿名行为记录。
- 用
LEFT JOIN保留全部行为记录，缺失字段为NULL，业务侧可后续判断是否补全 - 关联字段
user_id必须有索引，否则JOIN过程可能全表扫描 - 别在
WHERE里加u.city = '北京'这类右表条件——它会让LEFT JOIN退化成INNER JOIN；真要过滤，得写进ON子句：LEFT JOIN users u ON e.user_id = u.user_id AND u.city = '北京'
跨表计算“首次行为后第N日是否回访”，必须用LEFT JOIN + 日期偏移条件
如果目标不是单纯查首次/末次，而是做留存分析（比如“首日登录用户中，有多少人在第3天又来了”），那就绕不开LEFT JOIN，但关键在ON条件怎么写。
错误写法：LEFT JOIN user_events d ON e.user_id = d.user_id —— 这会把该用户所有后续行为都连进来，根本无法区分“第3天”还是“第30天”。
- 必须在
ON里同时约束user_id和目标日期：ON d.user_id = e.user_id AND DATE(d.event_time) = DATE_ADD(e.first_event, INTERVAL 3 DAY) - Hive/SparkSQL用
DATE_ADD(e.first_event, 3)（注意参数顺序），ClickHouse用plusDays(e.first_event, 3) - 分母必须来自首次行为子集，不能直接
GROUP BY DATE(event_time)——那统计的是日活，不是新增 - 分子用
COUNT(DISTINCT CASE WHEN d.user_id IS NOT NULL THEN e.user_id END)，靠d.user_id IS NOT NULL判断是否回访成功
大数据量下，先聚合再JOIN比直接JOIN更稳
当行为表有上亿行，且一个用户对应成百上千条记录时，直接LEFT JOIN会产生爆炸式中间结果，内存溢出（OOM）风险极高。
更可靠的做法是：先对行为表按user_id预聚合，再JOIN用户维表。
- 用CTE或子查询提前算好每人
first_event、last_event、total_events，生成轻量中间集 - 再把这个中间集
LEFT JOIN users，关联开销大幅降低 - 如果只需判断“有没有第3天回访”，用
EXISTS比LEFT JOIN更快，尤其右表无索引时 -
COUNT(*)在LEFT JOIN后永远不为0，它数的是左表行数；真要判空，得用COUNT(d.user_id)，因为NULL不计入
真正难的不是语法，而是想清楚：你要的到底是“每个用户的首次/末次”，还是“以首次为起点的后续行为模式”。前者单表聚合就够了，后者才需要谨慎设计JOIN逻辑和日期对齐条件。
