SQL JOIN 条件写在 ON 还是 WHERE 的差别是什么

来源:个人站长网作者:小团团头衔:草根站长
导读:本期聚焦于小伙伴创作的《SQL JOIN 条件写在 ON 还是 WHERE 的差别是什么》,敬请观看详情,探索知识的价值。以下视频、文章将为您系统阐述其核心内容与价值。如果您觉得《SQL JOIN 条件写在 ON 还是 WHERE 的差别是什么》有用,将其分享出去将是对创作者最好的鼓励。

在SQL多表查询的场景中,JOIN的关联条件可以写在ON子句里,也可以写在WHERE子句里,很多开发者会混淆两者的使用场景,甚至认为两者没有区别,实际上它们的执行逻辑和查询结果存在明显差异,尤其是在外连接查询中,放错位置会导致结果不符合预期。

SQL JOIN 条件写在 ON 还是 WHERE 的差别是什么

两种写法的核心差异

ON子句是JOIN操作的关联条件,用于在生成临时表时过滤参与连接的两表数据,决定哪些行可以匹配上;WHERE子句是在临时表生成之后,对最终结果集进行过滤的条件,会过滤掉不满足条件的所有行。

内连接场景下的差异

在内连接(INNER JOIN)中,ON和WHERE的条件过滤效果是一致的,因为内连接只会保留两表匹配的行,无论条件写在哪个位置,最终的结果集都不会有区别。

我们先创建两张测试表,表结构如下:

-- 用户表
CREATE TABLE user_info (
    id INT PRIMARY KEY,
    user_name VARCHAR(50)
);

-- 订单表
CREATE TABLE order_info (
    order_id INT PRIMARY KEY,
    user_id INT,
    order_amount DECIMAL(10,2)
);

-- 插入测试数据
INSERT INTO user_info VALUES (1, '张三'), (2, '李四'), (3, '王五');
INSERT INTO order_info VALUES (1001, 1, 199.00), (1002, 1, 299.00), (1003, 2, 399.00);

以下是内连接下两种写法的示例,查询结果完全一致:

-- 条件写在ON子句
SELECT u.id, u.user_name, o.order_id, o.order_amount
FROM user_info u
INNER JOIN order_info o
ON u.id = o.user_id AND o.order_amount > 200;

-- 条件写在WHERE子句
SELECT u.id, u.user_name, o.order_id, o.order_amount
FROM user_info u
INNER JOIN order_info o
ON u.id = o.user_id
WHERE o.order_amount > 200;

两种写法都会返回订单金额大于200的订单及对应的用户信息,结果如下:

iduser_nameorder_idorder_amount
1张三1002299.00

外连接场景下的差异

在外连接(LEFT JOIN、RIGHT JOIN)中,ON和WHERE的差异会非常明显。ON条件只会过滤被驱动表的数据,驱动表的数据会全部保留;而WHERE条件会过滤整个临时表的结果,可能导致驱动表的行被过滤掉。

以下是左连接(LEFT JOIN)的两种写法示例:

-- 条件写在ON子句,过滤订单表的金额
SELECT u.id, u.user_name, o.order_id, o.order_amount
FROM user_info u
LEFT JOIN order_info o
ON u.id = o.user_id AND o.order_amount > 200;

-- 条件写在WHERE子句,过滤最终结果集的金额
SELECT u.id, u.user_name, o.order_id, o.order_amount
FROM user_info u
LEFT JOIN order_info o
ON u.id = o.user_id
WHERE o.order_amount > 200;

第一种写法的结果会保留所有用户的信息,没有匹配到高金额订单的用户,订单相关字段显示为NULL:

iduser_nameorder_idorder_amount
1张三1002299.00
2李四NULLNULL
3王五NULLNULL

第二种写法的结果只会保留有高金额订单的用户,李四和王五因为没有符合条件的订单,会被WHERE条件过滤掉:

iduser_nameorder_idorder_amount
1张三1002299.00

执行顺序逻辑

SQL的查询执行顺序可以简单梳理为:

  • 先执行FROM子句,确定要查询的表
  • 执行ON子句,对JOIN的两表进行匹配,生成临时表
  • 执行WHERE子句,对临时表的结果进行过滤
  • 后续执行GROUP BY、HAVING、SELECT、ORDER BY等子句

从这个顺序可以看出,ON是在临时表生成阶段生效,WHERE是在临时表生成之后生效,这就是两者产生差异的根本原因。

使用建议

为了避免逻辑错误,建议遵循以下使用规则:

  • 如果是两表的关联匹配条件,统一写在ON子句中,不管是内连接还是外连接,都更清晰
  • 如果是对连接之后结果的过滤条件,写在WHERE子句中
  • 外连接场景下,如果需要过滤被驱动表的数据但保留驱动表全部数据,条件写在ON子句;如果需要过滤最终结果,条件写在WHERE子句
注意:不要因为内连接下两者效果一致就随意混用,当后续查询从内连接改为外连接时,条件位置错误会导致结果不符合预期,增加排查成本。

在实际开发中,只要明确ON和WHERE的执行阶段,就可以根据需求选择正确的写法,避免查询逻辑错误。

SQL_JOINONWHERE表连接修改时间:2026-07-21 22:33:33

免责声明:​ 已尽一切努力确保本网站所含信息的准确性。网站内容多为原创整理与精心编撰,观点力求客观中立。本站旨在免费分享,内容仅供个人学习、研究或参考使用。若引用了第三方作品,版权归原作者所有。如内容涉及您的权益,请联系我们处理。
内容垂直聚焦
专注技术核心技术栏目,确保每篇文章深度聚焦于实用技能。从代码技巧到架构设计,为用户提供无干扰的纯技术知识沉淀,精准满足专业提升需求。
知识结构清晰
覆盖从开发到部署的全链路。AI、前端、编程、数据库、服务器、建站、系统层层递进,构建清晰学习路径,帮助用户系统化掌握开发与运维所需的核心技术。
深度技术解析
拒绝泛泛而谈,深入技术细节与实践难点。无论是数据库优化还是服务器配置,均结合真实场景与代码示例进行剖析,致力于提供可直接应用于工作的解决方案。
专业领域覆盖
精准对应开发生命周期。从前端界面到后端编程,从数据库操作到服务器运维,形成完整闭环,一站式满足全栈工程师和运维人员的技术需求。
即学即用高效
内容强调实操性,步骤清晰、代码完整。用户可根据教程直接复现和应用于自身项目,显著缩短从学习到实践的距离,快速解决开发中的具体问题。
持续更新保障
专注既定技术方向进行长期、稳定的内容输出。确保各栏目技术文章持续更新迭代,紧跟主流技术发展趋势,为用户提供经久不衰的学习价值。