ROW_NUMBER() 可模拟 VLOOKUP 的首次匹配行为，需配合 PARTITION BY 和显式 ORDER BY 确保稳定性；LEFT JOIN 时须将 rn = 1 放 ON 条件而非 WHERE；FIRST_VALUE() 更适合多列返回；注意索引优化与大数据量下的性能陷阱。
用 ROW_NUMBER() 模拟 VLOOKUP 的“首次匹配”行为
SQL 没有原生 VLOOKUP，但多数场景要的是“按某字段查找第一条匹配记录”，这正好对应 ROW_NUMBER() + ORDER BY 的组合。关键不是“查到就行”，而是控制“查哪一条”。
- 必须显式指定
ORDER BY子句，否则ROW_NUMBER()结果不稳定（尤其在分布式引擎如 Spark SQL 或 Presto 中） - 若查找键存在重复，
ROW_NUMBER() OVER (PARTITION BY lookup_key ORDER BY priority DESC)可按业务优先级取最高分的一条 - 别用
RANK()或DENSE_RANK()—— 它们会为相同值分配相同序号，导致多行保留，破坏“单值返回”语义
用 LEFT JOIN + ROW_NUMBER() 实现“左表驱动”的 VLOOKUP 效果
Excel 的 VLOOKUP 默认左关联：左表每行查右表，没找到就留空。纯 JOIN 会丢行，必须用 LEFT JOIN，再过滤出每组第一条。
- 先对右表（即“查找表”）按关联键预计算序号：
SELECT *, ROW_NUMBER() OVER (PARTITION BY id ORDER BY updated_at DESC) AS rn FROM dim_user
- 再与左表
LEFT JOIN，并加条件ON t1.id = t2.id AND t2.rn = 1 - 注意：不能把
t2.rn = 1放WHERE子句——那会把左表无匹配的行也过滤掉
处理多列返回时，FIRST_VALUE() 比 ROW_NUMBER() 更简洁
当需要一次性取回姓名、部门、职级等多个字段，而不是只取一个字段再反复 JOIN，FIRST_VALUE() 是更直接的选择。
-
FIRST_VALUE(name) OVER (PARTITION BY user_id ORDER BY effective_date DESC)直接返回该组内按时间最新的 name - 必须搭配
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING，否则默认窗口范围可能截断结果 - MySQL 8.0+ 和 PostgreSQL 13+ 支持；旧版 MySQL 或 SQLite 需降级用子查询或
JOIN
性能陷阱：窗口函数不等于索引友好，大表慎用
很多人以为加了 PARTITION BY 就自动走索引，实际并非如此。窗口函数本质是全量排序或扫描，数据量一过千万，响应明显变慢。
- 确保
PARTITION BY字段上有索引，且该字段区分度高（避免PARTITION BY status这种只有 3–5 个值的低效分区） - 在 Hive/Spark 中，
ORDER BY若涉及非分区字段，会触发全局 shuffle，比单纯GROUP BY开销更大 - 真正高频、低延迟的 VLOOKUP 类需求（比如实时报表下钻），应优先考虑物化映射表或缓存层，而非每次跑窗口函数
窗口函数能模拟 VLOOKUP 的行为，但没法复制 Excel 那种“点一下就刷新”的交互体验——它始终是批处理逻辑，数据新鲜度、执行耗时、资源占用都得提前算清楚。
