小结果集用IN更直观，大结果集必须用EXISTS避免全表扫描；时间过滤需用>=和
WHERE 条件里用 IN 还是 EXISTS？看子查询结果集大小
小结果集（比如几十个用户 ID）用 IN 更直观；大结果集（比如上百万条日志筛选出的活跃用户）必须换 EXISTS，否则 MySQL 可能放弃索引走全表扫描。
常见错误现象：SELECT * FROM events WHERE user_id IN (SELECT DISTINCT user_id FROM users WHERE region = 'CN') —— 当子查询返回几万行时，外层 events 表几乎必然慢得离谱。
-
IN会把子查询结果缓存为临时列表，再做哈希匹配；超出内存阈值就写磁盘，性能断崖下跌 -
EXISTS是半连接（semi-join），每行外层记录只判断“是否存在”，可利用user_id索引快速探查 - MySQL 8.0+ 对
IN子查询做了物化优化，但仅限于简单子查询；含GROUP BY或聚合函数时仍不生效
时间范围过滤别只写 BETWEEN，小心时区和边界
用户行为日志的时间字段通常是 created_at，类型多为 DATETIME 或 TIMESTAMP。直接写 WHERE created_at BETWEEN '2024-01-01' AND '2024-01-31' 会漏掉 1 月 31 日全天数据——因为隐式转换成 '2024-01-31 00:00:00'。
- 正确写法是
created_at >= '2024-01-01' AND created_at ，既避免边界歧义，又利于索引使用 - 如果数据库时区是 UTC，而业务按北京时间统计，必须显式转换：
CONVERT_TZ(created_at, '+00:00', '+08:00')，否则凌晨 0–1 点的行为会被分到错误日期 -
TIMESTAMP字段自动转时区，DATETIME不转——混用时容易查不到数据，先SHOW VARIABLES LIKE '%time_zone%'确认当前会话时区
计算留存率时，LEFT JOIN 的 ON 条件不能写成 WHERE
想查“第 1 天登录、第 7 天还回来的用户数”，典型写法是自连接：主表是首日用户，副表是 7 天后行为。一旦把日期条件放进 WHERE，LEFT JOIN 就退化成 INNER JOIN，留存率永远是 100%。
错误示例：SELECT COUNT(*) FROM day1 u LEFT JOIN day7 v ON u.user_id = v.user_id WHERE v.event_time IS NOT NULL —— 这个 WHERE 把没回访的用户全过滤掉了。
- 日期条件必须放在
ON子句里：LEFT JOIN day7 v ON u.user_id = v.user_id AND v.event_time >= DATE_ADD(u.first_time, INTERVAL 7 DAY) - 计算分母（首日用户数）和分子（7 日回访用户数）必须用同一份
day1表，不能在WHERE里加额外过滤，否则基数失真 - 大表关联时，确保
user_id和时间字段都有联合索引，例如(user_id, event_time)
用 GROUP BY 做路径分析时，ORDER BY 必须显式指定
查“用户点击路径中，从商品页到购物车页的跳转占比”，常需 LAG() 取上一行页面，再 GROUP BY 统计。但 MySQL 默认不保证窗口函数执行前的行序——如果没有 ORDER BY，LAG(page) 可能取到任意前一行，结果完全不可信。
- 必须写成：
SELECT page, LAG(page) OVER (PARTITION BY user_id ORDER BY event_time) AS prev_page FROM events - 分区键
PARTITION BY user_id不能漏，否则跨用户取上一页，逻辑崩坏 - 如果
event_time有重复（比如毫秒级精度缺失），需加二级排序，例如ORDER BY event_time, event_id避免非确定性
复杂点在于：行为序列的完整性依赖事件采集 SDK 的埋点质量。漏报一次页面曝光，整个路径链就断了——分析前先用 COUNT(*) vs COUNT(DISTINCT user_id) 粗略看下去重率，低于 0.95 就得先查数据上报问题。
