news 2026/8/9 19:11:19

MySQL中多表查询的方式有哪些?

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
MySQL中多表查询的方式有哪些?

一、先明确:为什么必须掌握多表查询?

1.你是否能区分不同多表查询方式的差异?
2.能否根据业务场景选择合适的查询方式?
3.能否独立写出正确的多表查询 SQL?(避免语法错误)

二、先铺垫:多表查询的基础前提

先明确多表查询的核心:表与表之间必须有 “关联关系”(通常是主键 - 外键关联,比如用户表user的id(主键)对应订单表order的user_id(外键)),没有关联关系的多表查询会产生 “笛卡尔积”(数据冗余,无实际业务意义)。

先定义两个测试表:

-- 用户表(主表) CREATE TABLE `user` ( `id` INT PRIMARY KEY AUTO_INCREMENT, -- 用户ID(主键) `username` VARCHAR(50) NOT NULL, -- 用户名 `age` INT DEFAULT 0 -- 年龄 ); -- 订单表(从表) CREATE TABLE `order` ( `id` INT PRIMARY KEY AUTO_INCREMENT, -- 订单ID(主键) `order_no` VARCHAR(30) NOT NULL, -- 订单编号 `user_id` INT NOT NULL, -- 关联用户表的用户ID(外键) `price` DECIMAL(10,2) NOT NULL, -- 订单金额 FOREIGN KEY (`user_id`) REFERENCES `user`(`id`) -- 外键约束 );

三、核心多表查询方式拆解

方式 1:JOIN 连接查询

JOIN是多表查询的核心方式,通过关联字段将多个表 “拼接” 在一起查询,核心分为内连接、外连接(左外连接、右外连接)、交叉连接(极少用,仅作了解)。

1.1 内连接(INNER JOIN / JOIN)

通俗定义:只查询 “两张表中满足关联条件” 的数据,不满足条件的记录会被过滤掉(相当于 “取两张表的交集”)。

语法:SELECT 字段 FROM 表1 INNER JOIN 表2 ON 表1.关联字段 = 表2.关联字段 [WHERE 条件](INNER可省略,直接写JOIN)。

-- 简洁写法(省略INNER) SELECT u.id AS user_id, u.username, o.id AS order_id, o.order_no, o.price FROM `user` u JOIN `order` o ON u.id = o.user_id; -- 关联条件:用户ID=订单的用户ID

考察点:你是否知道ON用于指定表关联条件,WHERE用于过滤查询结果(避免把关联条件写在WHERE中)。

1.2 左外连接(LEFT JOIN / LEFT OUTER JOIN)

通俗定义:以 “左表” 为基准,查询左表的所有数据,右表中满足关联条件的数据会被匹配显示,不满足条件的右表字段显示NULL(相当于 “左表全量数据 + 右表交集数据”)。

语法:SELECT 字段 FROM 左表 LEFT JOIN 右表 ON 关联条件 [WHERE 条件](OUTER可省略)。

SELECT u.id AS user_id, u.username, o.id AS order_id, o.order_no, o.price FROM `user` u LEFT JOIN `order` o ON u.id = o.user_id;

考察点:能否区分左表和右表,理解 “右表不满足条件显示 NULL” 的特性。

1.3 右外连接(RIGHT JOIN / RIGHT OUTER JOIN)

通俗定义:以 “右表” 为基准,查询右表的所有数据,左表中满足关联条件的数据会被匹配显示,不满足条件的左表字段显示NULL(相当于 “右表全量数据 + 左表交集数据”),功能上可通过左连接互换表位置实现。

语法:SELECT 字段 FROM 左表 RIGHT JOIN 右表 ON 关联条件 [WHERE 条件](OUTER可省略)。

SELECT u.id AS user_id, u.username, o.id AS order_id, o.order_no, o.price FROM `user` u RIGHT JOIN `order` o ON u.id = o.user_id;

考察点:知道右连接的存在,理解其与左连接的对称关系。

1.4 交叉连接(CROSS JOIN,极少用)

通俗定义:无关联条件的连接,会产生两张表的 “笛卡尔积”(数据行数 = 表 1 行数 × 表 2 行数),通常无实际业务意义,仅在特殊场景(比如生成测试数据)使用。
• SQL 示例:

-- 产生笛卡尔积,慎用 SELECT u.username, o.order_no FROM `user` u CROSS JOIN `order` o;

方式 2:子查询(嵌套查询,适合简单场景)

通俗定义:将一个查询语句(子查询 / 内层查询)嵌套在另一个查询语句(主查询 / 外层查询)中,子查询的结果作为主查询的条件或数据源,分为 “关联子查询” 和 “非关联子查询”。

非关联子查询:子查询可独立执行,结果不依赖主查询(适合简单条件过滤)

  • 示例:查询 “购买过订单金额大于 100 元的用户” 信息
SELECT id, username, age FROM `user` WHERE id IN ( -- 子查询:获取订单金额>100的所有用户ID SELECT DISTINCT user_id FROM `order` WHERE price > 100 );

关联子查询:子查询依赖主查询的字段,无法独立执行(适合 “按主表每条记录匹配子表” 的场景)

  • 示例:查询 “每个用户的最新订单”(按订单 ID 倒序取第一条)
SELECT u.id AS user_id, u.username, o.id AS order_id, o.order_no, o.price FROM `user` u JOIN `order` o ON u.id = o.user_id WHERE o.id = ( -- 子查询:关联主表的user_id,取该用户最大订单ID(最新订单) SELECT MAX(id) FROM `order` WHERE user_id = u.id );

考察点:能否区分关联 / 非关联子查询,知道子查询的适用边界(避免多层嵌套导致性能问题)。

方式 3:联合查询(UNION / UNION ALL,结果集合并)

通俗定义:将多个SELECT查询的结果集合并成一个结果集,要求所有查询的 “字段数量、字段类型、字段顺序” 一致,分为UNION(去重,会过滤重复记录)和UNION ALL(不去重,性能更高)。

语法:SELECT 字段 FROM 表1 [WHERE 条件] UNION [ALL] SELECT 字段 FROM 表2 [WHERE 条件];

-- UNION:去重(自动过滤重复的用户记录) SELECT id, username, age FROM `user` WHERE age > 25 UNION SELECT u.id, u.username, u.age FROM `user` u JOIN `order` o ON u.id = o.user_id WHERE o.price > 200; -- UNION ALL:不去重(性能更高,适合确定无重复数据的场景) SELECT id, username, age FROM `user` WHERE age > 25 UNION ALL SELECT u.id, u.username, u.age FROM `user` u JOIN `order` o ON u.id = o.user_id WHERE o.price > 200;

考察点:知道UNION和UNION ALL的区别,明确联合查询的字段要求。

查询方式核心特点适用场景性能优先级
INNER JOIN取两表交集,过滤无效数据关联数据必须存在的业务(如已下单用户)高(优先使用)
LEFT JOIN保留左表全量数据,右表补 NULL需显示主表所有数据的场景(如所有用户订单)
子查询嵌套查询,逻辑直观简单条件过滤(如根据子查询结果筛选主表)中(复杂场景不如 JOIN)
UNION / UNION ALL合并结果集多查询结果合并(如不同条件的同类数据)中(UNION ALL > UNION)

加分项

1、结合项目举例:“我在实训项目中,用LEFT JOIN查询所有用户及对应的订单列表,用INNER JOIN查询有支付记录的用户信息”;

2、性能意识:“复杂多表查询优先用JOIN,不用多层子查询;合并结果集时,确定无重复数据就用UNION ALL,比UNION快”;

3、细节把控:“JOIN的关联条件写在ON里,过滤条件写在WHERE里,避免笛卡尔积冗余”。

举一反三

1、“如何查询‘没有订单记录的用户’?”(答案:LEFT JOIN后判断订单字段为NULL,SELECT u.* FROM user u LEFT JOIN order o ON u.id=o.user_id WHERE o.id IS NULL);

2. “ON和WHERE在JOIN查询中有什么区别?”(答案:ON是表关联条件,先执行;WHERE是结果过滤条件,在表关联后执行;LEFT JOIN中,ON不过滤左表数据,WHERE会过滤);

3. “多表查询时,如何提高性能?”(答案:给关联字段(主键 / 外键)建索引;避免SELECT *,只查需要的字段;减少笛卡尔积产生)。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/8/9 6:23:36

持续集成中的测试策略:构建高效质量保障体系

CI测试范式的演进 随着DevOps实践在2025年的深度普及,持续集成已从单纯的编译打包流程,演进为质量内建的核心阵地。现代CI管道中的测试策略,需要平衡速度与覆盖率、自动化与人工干预、单元测试与端到端验证的多重关系。根据Gartner最新调研&…

作者头像 李华
网站建设 2026/8/9 13:54:25

什么是持续集成CI,与DevOps关系

核心定义 持续集成是一种软件开发实践,其核心在于开发人员会频繁地(通常每天多次)将他们的代码更改集成到共享的主干分支中。每次集成都通过自动化的构建和测试来验证,以便尽早发现和修复错误,从而提高软件质量并缩短交…

作者头像 李华
网站建设 2026/8/9 15:55:45

结构类算法题

文章目录题目要求项目结构1.Action2.ColorableStep1:写接口和父类Step2:写实现类Step3:写测试类题目要求 项目结构 1.Action package ProgramDesign.Action;/*** 接口* 1. 方法的定义(抽象方法、静态方法、默认修饰权限)*/ public interface Action { /…

作者头像 李华
网站建设 2026/8/9 16:31:19

为什么你的Open-AutoGLM部署总失败?Docker最佳实践全解析

第一章:Open-AutoGLM部署失败的常见根源在部署 Open-AutoGLM 时,开发者常因环境配置、依赖冲突或权限设置不当导致服务无法正常启动。这些问题虽不显眼,却会显著延长调试周期,影响项目进度。环境依赖版本不匹配 Open-AutoGLM 对 P…

作者头像 李华
网站建设 2026/8/9 8:14:20

Open-AutoGLM安装总失败?深度解析Python依赖树中的隐藏陷阱

第一章:Open-AutoGLM安装失败的常见现象与初步诊断在部署 Open-AutoGLM 过程中,用户常遇到安装失败问题,这些故障通常表现为依赖缺失、环境冲突或权限异常。识别典型现象并进行快速诊断是解决问题的第一步。典型安装失败表现 执行 pip instal…

作者头像 李华