left join 正确模拟 vlookup 需满足三点：on 用等值条件且过滤逻辑不放 where；右表关联键须唯一（如用 row_number() 去重）；字段类型、空格、大小写需显式对齐并建索引。
LEFT JOIN 就是 SQL 里的 VLOOKUP，但 ON 条件写错就全废了
直接说结论：用 LEFT JOIN + 正确的 ON 等值条件，就能最贴近 VLOOKUP 行为——左表行数不变，右表匹配不上就填 NULL。但很多人把匹配逻辑误写进 WHERE，结果变成 INNER JOIN，悄悄丢掉查不到的行。
常见错误现象：
-
SELECT * FROM orders o LEFT JOIN customers c ON o.customer_id = c.id WHERE c.name IS NOT NULL—— 这句实际过滤掉了所有c.name为NULL的行，等价于内连接 - VLOOKUP 返回 #N/A 的地方，SQL 却一行都不见了
正确做法是把“是否查到”判断留在 SELECT 或后续逻辑里，比如：COALESCE(c.name, '未知客户') 或 CASE WHEN c.id IS NULL THEN '未匹配' ELSE c.name END。
右表有重复键？VLOOKUP 只认第一个，SQL 不会自动帮你选
VLOOKUP 遇到多条匹配，只取物理顺序第一行；LEFT JOIN 则会炸出多行（一对多），导致主表数据膨胀——这是线上事故高发区。
必须提前控制右表键唯一性，不能靠“目前没重复”赌运气：
- 用
ROW_NUMBER() OVER (PARTITION BY id ORDER BY updated_at DESC)取最新一条 - 封装成 CTE 或子查询，例如：
WITH unique_customers AS (SELECT id, name FROM (SELECT id, name, ROW_NUMBER() OVER (PARTITION BY id ORDER BY created_at DESC) rn FROM customers) t WHERE rn = 1) - 或者加
GROUP BY+ 聚合函数（如MAX(name)），但语义不如ROW_NUMBER()明确
别跳过这步。生产环境只要右表某天导入重复 ID，报表就崩。
字段类型不一致或带空格？= 判断比 Excel 严格得多
Excel 的 VLOOKUP 对 "123" 和 123、"abc " 和 "abc" 常有隐式容错；SQL 的 = 是精确字节/类型匹配，差一点就 NULL。
实操建议：
- 检查两边字段类型：
orders.customer_id是INT，但customers.id是VARCHAR？得显式转换：o.customer_id = CAST(c.id AS INT) - 字符串匹配前先
TRIM()：TRIM(o.code) = TRIM(c.code)，尤其来自 Excel 导入的数据 - 大小写敏感？看数据库
collation，必要时加LOWER()统一处理
类型不一致不会报错，只会默默不匹配——查半天发现是 VARCHAR 和 BIGINT 在打架，很浪费时间。
性能卡在 JOIN 上？索引要建在右表的 ON 字段
VLOOKUP 查一列很快，但 SQL 的 LEFT JOIN 如果没索引，就是 O(n×m) 全表扫描，十万行起步就明显卡顿。
关键点：
- 索引必须建在
ON右侧字段上，也就是被查表的关联列（如customers.id），不是左表的orders.customer_id - 复合条件？比如
ON a.x = b.x AND a.y = b.y，考虑建联合索引(x, y) - 用
EXPLAIN看执行计划，确认是否走了索引；没走就别怪慢
最容易被忽略的是：明明建了索引，但字段类型不一致导致索引失效——先 fix 类型，再谈性能。
