LEFT JOIN 是 SQL 中最贴近 VLOOKUP 的操作，需满足三点：ON 用等值条件且不移入 WHERE；右表关联键必须唯一（如用 ROW_NUMBER() 去重）；字段类型、空格、大小写须显式对齐并建索引。
SQL JOIN 就是 VLOOKUP 的“正统替代方案”，但直接照搬 Excel 思路会翻车——它不返回 NULL 时的默认值，也不自动去重，更不会只取第一个匹配项。
用 LEFT JOIN 模拟 VLOOKUP 的基础行为
VLOOKUP 默认查找不到就返回 #N/A，对应 SQL 就是保留左表所有行、右表匹配字段为 NULL。必须用 LEFT JOIN，不能用 INNER JOIN（后者会丢掉查不到的行）。
- 匹配字段类型要严格一致：比如左表
order_id是INT，右表对应字段不能是VARCHAR，否则隐式转换可能失效或变慢 - 连接条件写在
ON子句里，不是WHERE——误写进WHERE会让LEFT JOIN退化成INNER JOIN - 示例：从
orders表查客户名，参考customers表
SELECT o.order_id, o.amount, c.customer_name FROM orders o LEFT JOIN customers c ON o.customer_id = c.id;
处理重复匹配：VLOOKUP 只取第一个，SQL 默认全返回
VLOOKUP 遇到多条匹配时只返回第一条；而 SQL 的 JOIN 会生成笛卡尔积式的结果，导致主表一行变多行——这是最常被忽略的逻辑偏差。
- 如果确认右表
id字段有重复，先用GROUP BY+ 聚合（如MAX()）或DISTINCT ON（PostgreSQL）压制 - MySQL 8.0+ 可用窗口函数限制每组只取一行：
ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY updated_at DESC) - 简单场景下，加
LIMIT 1不可行——它作用于整个结果集，不是每组
模拟 VLOOKUP 的“精确匹配”与“模糊匹配”切换
VLOOKUP 第四个参数为 FALSE 是精确匹配（常用），TRUE 是升序近似匹配（少用但关键）。SQL 中：
- 精确匹配 → 直接
=连接，无额外操作 - 近似匹配（如找小于等于某日期的最新价格）→ 不能靠
JOIN一步到位，需子查询或LATERAL（PostgreSQL）/CROSS APPLY（SQL Server） - 示例（找每个订单下单前的最新折扣率）：
SELECT o.order_id, o.order_date,
(SELECT rate FROM discounts d
WHERE d.valid_from <= o.order_date
ORDER BY d.valid_from DESC LIMIT 1) AS discount_rate
FROM orders o;
性能和可维护性比“像不像 VLOOKUP”更重要
强行让 SQL 行为贴近 Excel，容易写出难读、难调、难优化的语句。比如用多重子查询模拟嵌套 VLOOKUP，不如提前物化中间表或加索引。
- 确保
JOIN字段有索引，尤其是右表的被查找列（如customers.id） - 避免在
ON条件里对字段做函数操作，例如ON UPPER(a.code) = UPPER(b.code)会导致索引失效 - 如果业务上真需要“取第一个匹配”，说明右表数据质量可能有问题——优先治理源数据，而不是在 SQL 层打补丁
真正棘手的从来不是语法怎么写，而是搞清“到底要哪一条匹配”——这往往得翻需求文档，而不是看 Excel 示例单元格。
