用max()窗口函数替代子查询可提升性能，需正确使用partition by；取完整记录应选row_number()而非rank()；lag/lead不能替代最大值提取；索引和时间字段类型影响性能。
用 MAX() 窗口函数替代子查询取时间最大值
直接在 SELECT 里写 MAX(timestamp) OVER (PARTITION BY user_id)，比关联子查询快得多——因为避免了对每行重复扫描原表。子查询在 WHERE 或 SELECT 里每次都要重新执行，而窗口函数只遍历一次数据。
常见错误是写成 MAX(timestamp) OVER ()（漏掉 PARTITION BY），结果所有行都得到全局最大时间，不是每个分组内的最大值。
- 必须明确写
PARTITION BY字段，否则逻辑完全错位 - 如果要取“最大时间对应的那一整行”，
MAX()窗口函数不够——它只返回值，不保留其他字段 - PostgreSQL 和 MySQL 8.0+、SQL Server 2017+ 支持；MySQL 5.7 及更早版本不支持，会报错
ERROR 1064
取“最大时间那条完整记录”该用 ROW_NUMBER() 还是 RANK()
用 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY timestamp DESC) 更稳妥。它保证每行编号唯一，即使时间相同，也能选中其中一条（按引擎默认顺序）。
RANK() 在时间相同时会给并列编号（比如两个最大时间都标为 1），后续再用 WHERE rn = 1 就可能返回多行，业务上常不满足“只取一条最新”的需求。
- 排序字段建议补上二级排序，比如
ORDER BY timestamp DESC, id DESC，让结果可预期 - Oracle 和 SQL Server 中
ROW_NUMBER()行为一致；但 HiveQL 的ROW_NUMBER()不支持在WHERE中直接引用别名，得套一层子查询 - 别在
ORDER BY里用表达式如DATE(timestamp)，会导致索引失效，查得慢
LAG() / LEAD() 能不能代替最大值提取
不能。这两个函数只能取相邻行的值（比如上一条/下一条的时间），不是聚合意义上的“最大”。想确认某条记录是不是组内最新？可以结合 LEAD(timestamp) 判断下一行是否为空，但这属于间接推导，且无法处理多条同为最大时间的情况。
-
LEAD(timestamp) OVER (PARTITION BY user_id ORDER BY timestamp)返回的是“下一个时间”，不是“最大时间” - 如果当前行
LEAD()为NULL，只能说明它是排序后的末尾行，不一定等于MAX()（比如按id排序就完全无关） - 用错函数最典型的报错是：明明要最新登录时间，结果取出的是最新登录时间的下一次登录时间
时间字段类型和索引对窗口函数性能的影响
窗口函数本身不自动走索引，但 PARTITION BY 和 ORDER BY 字段如果有联合索引，能显著减少排序开销。例如建索引 CREATE INDEX idx_user_time ON events(user_id, timestamp DESC)，比单列索引高效得多。
容易被忽略的是时间字段类型：用 STRING 存 "2023-10-01 12:34:56" 然后在 ORDER BY 里直接排，表面能跑通，实际按字典序比较，2023-09-30 会排在 2023-10-01 前面——因为 '0' ROW_NUMBER() 排序错乱。
- 务必用
TIMESTAMP或DATETIME类型存时间，别用字符串 - MySQL 中
TIMESTAMP有 timezone 隐式转换风险，生产环境更推荐DATETIME - 分区键字段若存在大量
NULL，部分数据库（如 PostgreSQL）会把它们单独归为一组，影响PARTITION BY分组数量
