数据库left join到底咋回事，顺带聊聊怎么能让查询跑得快点

LEFT JOIN 到底咋回事？

想象一下，你有两张表格，一张是“员工表”，记录了所有员工的基本信息，比如员工ID、姓名、部门ID，另一张是“部门表”，详细说明了每个部门ID对应的部门名称、办公室地点等。

现在你想拉一个名单，列出所有员工的名字，并且如果可能的话,在旁边显示他们所属部门的名字和地点。

这时候，LEFT JOIN 就派上用场了，它的核心思想就是：以左边的表为主，绝不丢弃任何一条记录。

• 左边的表（主表）：在这个例子里就是“员工表”，你希望名单上一个员工都不能少，哪怕是新来的还没分配部门,或者因为某些原因部门ID填错了。
• 右边的表（被连接的表）：部门表”,它的任务是提供补充信息。

LEFT JOIN 的工作过程大概是这样的：

1. 数据库先拿出员工表的第一条记录，比如张三,他的部门ID是101。
2. 然后它就去右边的部门表里，翻箱倒柜地找有没有部门ID等于101的记录。 3 如果找到了，太好了！它就把张三的信息，和部门表里找到的部门名称、地点等信息，拼成一条完整的新记录,放到结果里。
3. 如果没找到（比如张三的部门ID填成了999，但部门表里根本没有999这个部门），怎么办？LEFT JOIN 的态度是：没关系！主表的记录必须保留，它仍然会把张三的信息放到结果里，但是对于本该来自部门表的所有栏目（部门名称、地点等），它就全部填上 NULL（你可以理解为“空”或者“未知”）。

查询结果会包括：

• 所有有明确部门的员工,信息是完整的。
• 所有部门ID不对或者没部门的员工，他们个人信息还在,但部门相关信息是空的。

这和另一种叫 INNER JOIN 的连接方式完全不同，INNER JOIN 是“必须匹配”，如果张三在部门表里找不到对应的部门，他整个人就不会出现在最终结果里，就像被开除了一样，而 LEFT JOIN 则保证了主表员工的“全员出席”。

顺带聊聊怎么能让查询跑得快点

LEFT JOIN 本身是个好工具，但如果表很大，或者写得不好，查询速度可能会慢得像蜗牛，怎么给它提提速呢？关键在于帮数据库减少“翻箱倒柜”的工作量。

1. 建索引，就像给书加目录 这是最重要、最有效的一招，还拿上面的例子说，数据库去部门表里找ID=101的记录，如果部门表有几十万条记录，它就得从头到尾扫描一遍，这叫“全表扫描”，非常慢。 如果你在部门表的“部门ID”这个栏目上创建了索引，那就不一样了，索引就像一本书的目录，数据库不用翻整本书，直接查目录就能瞬间定位到ID=101的记录在哪一页，应该在 JOIN 条件里用到的字段（比如例子中的“部门ID”）和 WHERE 子句里经常用来筛选的字段上创建索引，根据人民邮电出版社出版的《SQL必知必会》中的观点,索引是提高查询性能最有力的工具。

   

2. 只取需要的列，别用 SELECT ** 很多人图省事，直接写 `SELECT `，意思是把两个表所有的列都拿出来，但如果员工表有20列，部门表有15列，而你最终只需要员工姓名和部门名称这两列，数据库却要搬运总共35列的数据，这无疑是巨大的浪费。 正确的做法是，需要什么列，就明确写出来**，SELECT 员工.姓名， 部门.名称，这样数据库需要处理的数据量会小很多,速度自然就快了。

3. 尽量减少 JOIN 表的数量 一条SQL语句里如果LEFT JOIN了七八张表，复杂度会急剧上升，数据库需要一层一层地去匹配，性能很难保证，在可能的情况下，要审视查询是否真的需要连接这么多表，拆分成几个简单的查询，在程序里分步处理,总体的响应速度反而更快。

4. 利用 WHERE 条件提前过滤 如果你的查询最终只要看“销售部”的员工，那么聪明的写法是在连接部门表之后，立刻用 WHERE 部门.名称 = ‘销售部’ 来过滤，这样，那些不满足条件的记录在早期就被排除了，后续的连接和计算量会大大减少，不过要注意，如果WHERE条件用在被LEFT JOIN的表上，可能会改变LEFT JOIN“保留所有主表记录”的性质，有时候需要谨慎处理，根据数据库技术社区常见的性能优化建议,有效的过滤条件应尽可能早地发挥作用。

5. 别在JOIN条件里做计算 避免写类似 ON 员工.ID = 部门.ID + 100 或者 ON UPPER(员工.姓名) = UPPER(部门.负责人) 这样的条件，因为一旦对字段进行了函数运算，数据库通常就无法使用之前建好的索引了，又得被迫进行全表扫描，尽量让JOIN条件保持“干净”。

LEFT JOIN就是个“保主舍次”的查询法宝，想让它们跑得快，核心思想就是给数据库减负：用索引让它查得快，用明确字段让它搬得少，用高效条件让它算得省，这些方法结合起来,你的查询效率就会有明显的提升。