left join、right join和join，傻傻分不清？

嘿，我以前做过这个，建立表连接。
我记得2 01 4 年在杭州帮助一个客户做数据集成，这在当时确实是一个新鲜事。
我花了很长时间才理解左连接、右连接和内连接的区别。

我当时正在使用MySQL。
我们以两张表为例，一张是课程表（kemu），一张是成绩表（point）。
当时，课程表包含课程编号和名称，成绩表存储学生选择的科目和各自的成绩。

当时我用的最多的是LEFT JOIN。
例如，我想查看所有学生都选择了哪些科目，结果发现有些学生可能没有选择任何科目。
这就是左连接派上用场的地方。
它将列出所有学生信息，即使他们没有选择课程，成绩栏也会为空。

有一次，一位客户问我：“右边的空白表格该怎么办？”我说：那是因为学生还没有选科目。
结果他瞪大了眼睛，道：“啊？如果所有的学生都选课了怎么办？”哈哈，当时对我来说就像相声一样。

还有一次，我使用 RIGHT JOIN 进行检查。
客户想知道哪些学生注册了所有课程，包括哪些学生没有注册。
我这样做了，右边的所有课程信息都出现了。
左边未选课的学生成绩均为NULL。
我记得当时我为自己感到非常自豪。

当时也常用Inner JOIN。
我记得有一次，一位客户想要特定班级所有学生的成绩单，所以我直接使用内部链接来链接课程和记分卡。
结果集是该班学生的所有成绩信息。

总结一下，左边的链接就像一个综合性的学习，右边的链接就像一个片段，而内连接就像两个圆圈的重叠部分。
这取决于您想要接收的信息以及您选择的连接方法。

对了，还有一种缩写联接（JOIN），它是内部联接。
我以前是直接写JOIN来简化操作的，但是要注意的是，默认是内连接。

总之，那段时间我学到了很多东西。
虽然现在想起来有点初级，但当时的迷茫和成就感依然记忆犹新。
😄

MySQL原理总结之左连接、右连接、内连接与Hash连接

你的总结很详细，但是让我们谈谈我遇到的陷阱。

记得去年在一个电商项目中，我们使用LEFT JOIN来查看用户订单，但是性能极其缓慢。
如果您考虑一下，Users 表有数百万个条目，Orders 表有数百万个条目。
如果直接进行左连接，数据库就会变得愚蠢。
它会一一匹配并最终填充一堆 NULL。
硬盘会疲劳。
接下来发生了什么？添加索引，将用户ID添加到orders表的索引中，查询会更快。
所以，left join固然好，但是当表很大的时候，就需要加索引了，不然不行。

还有一次，我在旧系统上进行正确的连接，但系统崩溃了。
想想看，右边的表很大，有几十G的数据。
系统将其视为驱动器表。
内存突然满了，磁盘开始旋转。
最终，它屈服了。
后来改成了Inner Join，用数据量较小的表作为驱动表，然后排序。
所以，虽然也可以使用true join，但是如果表太大的话就得小心了。

内部联系用得很多，尤其是订单之间的关系以及订单明细的关系清晰，效率确实很高。
在之前的项目中，我在订单表和订单详细信息表之间使用了内部连接，并将订单表链接到驱动程序被用作桌子。
由于orders表很小，所以查询速度很快。
确实有效。

我没有遇到过很多hash连接，但是在一个大数据分析项目上尝试过一次。
数据量确实很大，好几TB的数据，用哈希直接链接起来。
数据库首先在内存中创建一个哈希表，然后逐步匹配它。
结果内存不够了，最终转移到磁盘上。
虽然最终找到了，但需要很长时间。
后来我们加了一些内存再试，速度好了很多。
因此，哈希连接对内存的要求非常高。
数据量大了，需要加更多的内存，不然真的会卡住。

一般情况下，应根据实际情况选择连接查询。
表大小、索引位置和内存大小都需要考虑。
千万不要一出现就乱用，否则很容易出事。