多字段JOIN需用AND连接条件，如ON t1.a = t2.a AND t1.b = t2.b；必须为被驱动表建与ON顺序一致的复合索引，否则性能骤降。
直接用 ON 后接多个条件，用 AND 连接即可，不需要额外语法或括号包裹。
多个字段 JOIN 的写法和常见错误
实际业务中，单字段连接经常不够用——比如订单表和发货表可能需要同时匹配 order_id 和 warehouse_id，否则会把不同仓库的同订单号数据混在一起。
-
ON后面直接写多个等值条件，用AND拼接，例如：ON t1.a = t2.a AND t1.b = t2.b - 不要写成
ON (t1.a = t2.a, t1.b = t2.b)—— 这是语法错误，括号不能替代AND - 避免漏加表前缀，尤其当两个表都有
id字段时，ON id = id会报错，必须写成ON t1.id = t2.id - 字段类型要严格一致：比如
INT和BIGINT在某些数据库（如 MySQL 8.0+）隐式转换可能成功，但VARCHAR和TEXT就可能失败或性能极差
什么时候必须用多字段 JOIN？
不是“想用就用”，而是业务逻辑强制要求——单字段无法唯一确定关联关系时，就必须补上约束条件。
- 复合主键场景：比如日志表按
(date, service_name, host)组合唯一，JOIN 时缺一不可 - 分库分表后迁移数据：原表用
tenant_id + user_id做联合标识，JOIN 时这两个字段都得对齐 - 历史数据补全：旧系统用
region_code+year定位统计记录，新表也得按这两列对齐才不会错行 - 注意：如果只是“想提高精度”，但业务上单字段已能保证唯一性（比如
order_id本身全局唯一），加多余字段反而增加索引压力、拖慢执行
多字段 JOIN 对性能和索引的影响
数据库优化器是否走索引，取决于你有没有建对复合索引，而不是 JOIN 写得多漂亮。
- MySQL 的
INNER JOIN默认用嵌套循环，如果右表没索引，会全表扫描——哪怕只多加一个AND条件也救不了 - 必须为
ON中涉及的所有字段建复合索引，且顺序要和ON中出现顺序一致，例如：ON t1.a = t2.a AND t1.b = t2.b，那t2上得有(a, b)索引，(b, a)不行 - PostgreSQL 支持位图索引合并，对多字段条件容忍度稍高，但依然建议建对应复合索引
- WHERE 中再加其他过滤条件（比如
AND t1.status = 'done'）时，索引是否生效要看整体谓词选择性，别默认“加了索引就一定快”
最常被忽略的是字段顺序和索引顺序的一致性——写对了 ON 条件，却忘了在被驱动表上建对应顺序的复合索引，结果查询从毫秒变秒级。
