在关系型数据库里，一张表往往只负责一类数据。比如电商系统会把用户基本信息放在 user 表，把订单记录放在 orders 表，订单通过一个 user_id 字段和用户关联起来。当业务需要查询“某个订单是谁下的”这类问题时，就必须把两张表连起来查，这时 INNER JOIN 就派上用场了。它是 SQL 中使用频率最高的连接方式，写法简单，语义清晰，掌握它基本就能应对大部分日常查询场景。
先理解主外键关系与内连接的原理
所谓主键，是表中唯一标识一条记录的字段，比如 user 表的 id。外键则是另一张表中指向这个主键的字段，比如 orders 表里的 user_id。这种主外键搭配构成了表与表之间的逻辑纽带，也是连接查询能成立的前提。
INNER JOIN 的执行逻辑可以概括为一句话：从两张表中取出满足连接条件的记录组合，其余全部丢弃。举个例子，user 表有 id 为 1、2、3 的三条用户数据，orders 表里有 user_id 为 1、1、3 的三条订单，那么内连接的结果就只有三条：两条属于用户1，一条属于用户3，用户2因为没有订单，永远不会出现在结果里。这一点是内连接和左连接最本质的区别，后面会专门对比。
从底层执行角度看，数据库引擎会根据连接字段上的索引决定执行计划。如果 orders.user_id 上建了索引，引擎通常走索引查找，效率很高；没有索引则可能退化为全表扫描逐条匹配，数据量大时性能会明显下降。所以在设计表结构时，给外键字段加索引是很有必要的习惯。
两表连接的基础写法与注意点
下面用一组建表语句搭建演示环境，两张表的关系是典型的“一对多”：一个用户可以有多条订单。
-- 用户表
CREATE TABLE user (
id INT PRIMARY KEY,
name VARCHAR(50),
city VARCHAR(50)
);
-- 订单表，user_id 是外键
CREATE TABLE orders (
order_id INT PRIMARY KEY,
user_id INT,
amount DECIMAL(10,2),
created_at DATETIME
);
INSERT INTO user VALUES (1, '张三', '北京'), (2, '李四', '上海'), (3, '王五', '广州');
INSERT INTO orders VALUES (101, 1, 299.00, '2024-01-10'),
(102, 1, 158.50, '2024-02-15'),
(103, 3, 899.00, '2024-03-02');
最基础的查询是查出每个订单对应的用户姓名：
SELECT u.name, o.order_id, o.amount
FROM user AS u
INNER JOIN orders AS o
ON u.id = o.user_id;
结果会返回三行，李四因为没有任何订单不会出现。这里有几个写法上的细节值得注意。第一，给表起别名（u、o）不是必须的，但强烈建议养成习惯，否则每个字段都要写全 user.name、orders.order_id，语句会很长。第二，连接条件写在 ON 子句里，条件必须明确写出来，内连接的 ON 不能省略，这一点和外连接不同。第三，如果两张表里有同名字段，引用时必须加表前缀，否则数据库会报“列名不明确”的错误。
WHERE 和 ON 都能写过滤条件，但语义有区别。ON 后面放连接条件，WHERE 后面放结果过滤条件，这样语句的可读性最好。对于内连接来说，把过滤条件写在 ON 还是 WHERE 里，最终结果是一样的，但为了代码规范，建议按职责分开书写。
多表连接与常见的组合用法
实际业务往往不止两张表。比如订单还关联了商品表 goods，想查出“订单号、用户名、商品名、金额”的完整信息，就需要连续连接三张表。INNER JOIN 可以链式写多个，语法结构完全一致：
SELECT o.order_id, u.name, g.goods_name, o.amount FROM orders AS o INNER JOIN user AS u ON o.user_id = u.id INNER JOIN goods AS g ON o.goods_id = g.goods_id WHERE o.amount > 100 ORDER BY o.amount DESC;
链式连接的执行顺序是从左往右逐步累加结果集：先得到订单和用户的中间结果，再拿这个中间结果去和商品表匹配。连接的表数量建议控制在合理范围内，超过五六张时要考虑查询性能，也可以借助 EXPLAIN 语句查看执行计划，确认是否命中了索引。
内连接配合聚合函数也很常见。比如统计每个用户的订单数和消费总额，把 WHERE 换成 GROUP BY 即可：
SELECT u.name, COUNT(o.order_id) AS order_count, SUM(o.amount) AS total FROM user AS u INNER JOIN orders AS o ON u.id = o.user_id GROUP BY u.id, u.name;
注意这里 GROUP BY 用的是 u.id 而不是 u.name。名字理论上可能重复，用主键分组才能保证统计口径准确。这也是新手容易忽略的细节。
内连接与左连接的差异及常见坑
INNER JOIN 最大的特点是“宁缺毋滥”，两边都有的数据才输出。如果业务需求是“列出所有用户，包括从没下过单的”，内连接就不适用了，要改用 LEFT JOIN，它以左表为准，右表没匹配上的字段填 NULL：
-- 左连接：没有订单的用户也会出现，订单字段为 NULL SELECT u.name, o.order_id FROM user AS u LEFT JOIN orders AS o ON u.id = o.user_id;
选择哪种连接，取决于业务想不想要“没有匹配”的那部分数据。统计成交用户用内连接，统计全量用户活跃情况用左连接，两者不能混用。
最后说几个高频踩坑点。最严重的是连接条件漏写或写错，导致笛卡尔积：两张一万行的表如果没有 ON 条件，结果集会膨胀到一亿行，直接拖垮数据库。其次，连接字段类型要一致，user.id 是 INT 而 orders.user_id 是 VARCHAR 时，隐式类型转换会让索引失效，速度大幅变慢。再有就是 NULL 值参与连接时永远不会匹配成功，因为 NULL 和任何值比较结果都是未知，如果外键字段可能存在 NULL，要先用 WHERE 过滤或用 IS NULL 单独处理。
总结一下，写内连接查询时记住三步：明确表之间的主外键对应关系，用 ON 写清楚连接条件，需要过滤或统计时再加 WHERE 和 GROUP BY。把这三步练熟，多表查询基本就不会出问题。
INNER JOIN多表查询SQL主外键修改时间：2026-09-08 00:20:33