用 SQL 的 LEFT JOIN 来替换 Excel 的 VLOOKUP，这事儿说起来简单，但实际操作中，稍不留神就会踩坑。核心问题不在于语法本身，而在于这两种工具对“匹配”的理解完全不同。
VLOOKUP 默认只返回第一个匹配项，而 LEFT JOIN 会忠实地返回所有符合连接条件的结果组合。也就是说，如果你辅助表中存在重复键，JOIN 的结果行数就会爆炸性增长，产生笛卡尔积式的膨胀——这和 VLOOKUP 的“所见即所得”完全不是一回事。
用 LEFT JOIN 模拟精确单值查找
大多数时候，我们用 VLOOKUP 是为了根据主表的某个字段，去辅助表里找对应的单值，比如根据客户 ID 查客户姓名。SQL 里最接近的做法就是 LEFT JOIN：
- 主表放在 FROM 子句，辅助表写在 LEFT JOIN 后面——这个顺序不能反，否则查不到的数据会被直接丢弃，逻辑就变了。
- 连接条件必须严格对应字段类型和空值处理。比如 TEXT 和 VARCHAR 在某些数据库中会因大小写或尾部空格导致匹配失败，这时候 VLOOKUP 反而更宽容。
- 最头疼的是重复键问题：如果辅助表里同一个 product_id 对应多条记录，LEFT JOIN 会生成多行结果，而 VLOOKUP 只取第一行。要解决这个，要么加 DISTINCT，要么用子查询预先去重。
举个例子，从 orders 表查客户名：
SELECT o.order_id, o.customer_id, c.customer_name FROM orders o LEFT JOIN customers c ON o.customer_id = c.id;
处理近似匹配（range lookup）
Excel 的 VLOOKUP 还有一个隐藏技能——近似匹配，也就是第四个参数设为 TRUE，用于区间查找，比如根据分数查等级、按时间查费率。SQL 里可没有直接的等价语法，得靠 JOIN 加上范围条件来实现：
- 连接条件不能用等号，改成 ON 中带 BETWEEN 或比较运算符，比如
o.amount BETWEEN r.min_amount AND r.max_amount - 这种写法容易遗漏边界或造成重叠匹配。建议先确认参考表的区间定义是否无重叠、无缝隙，否则一条记录可能匹配到多行。
- 性能是个大问题。当参考表数据量较大时，数据库无法用普通索引加速范围 JOIN。必要时得建函数索引，或者改用 LATERAL（PostgreSQL）、APPLY（SQL Server）这类高级写法。
看这个例子，按订单金额查适用费率：
SELECT o.order_id, o.amount, r.rate FROM orders o LEFT JOIN rates r ON o.amount >= r.min_amount AND o.amount <= r.max_amount;
避开那些常见的坑：NULL、重复键、大小写与字符集
在实际把 VLOOKUP 迁移到 SQL 的过程中，80% 的问题出在数据质量，而不是语法本身。
VLOOKUP 会忽略首尾空格，但 SQL 默认不忽略——'A ' 和 'A' 在 SQL 眼里是两个不同的值。建议在连接前统一用 TRIM() 处理字符串字段。
Excel 把空单元格当成空字符串，但 SQL 里可能是 NULL。而 NULL = NULL 的结果是 UNKNOWN（不是 TRUE），这会导致 JOIN 失败。你需要显式写成 (a.key = b.key) OR (a.key IS NULL AND b.key IS NULL)，不过更推荐的做法是直接清洗掉 NULL。
辅助表主键不唯一？这是最致命的问题。VLOOKUP 会默默取第一行，但 SQL 的 JOIN 会让结果行数膨胀到你无法想象。务必先跑一下 SELECT COUNT(*) FROM ref_table GROUP BY join_key HA VING COUNT(*) > 1 检查重复。
还有字符集问题：MySQL 里的 utf8mb4_unicode_ci 默认忽略大小写和重音，但 VLOOKUP 是区分大小写的。如果业务要求严格匹配，得用 _bin 排序规则或者显式加 BINARY 转换。
说到底，真正难的不是写对那条 JOIN 语句，而是确认两边数据的“相等”定义是否一致。空格算不算相同？大小写要不要区分？NULL 算不算有效键？把这些细节搞清楚了，结果才能和 Excel 对齐。
