SQL连接查询中上与下筛选差异的总结
前言我相信对于每一个程序员来说，SQL查询都很简单，而且很简单。在一般情况下，所有功能都可以通过添加或删除的实现，检查和编程语言的逻辑表达能力匹配。但增删并不能代表所有的SQL语句，和完整的SQL函数将敬畏。就拿常见的CRUD稍微复杂层次的查询，盲目使用，会有危险的结果与预期相反，导致程序出现莫名其妙的错误。
在查询语法中，其他人首当其冲的会是混淆，在筛选和筛选的差异上，我们写查询时间，或者把筛选条件放在后面放在哪里，检查结果总是一样的，那么为什么要做一个不必要的动作让SQL查询支持两种过滤呢事实上，这两个过滤器是不同的，但他们不容易找到，如果他们不挖。
连接查询在SQL分为3种类型，交叉连接，内连接，外连接，交叉连接和内部连接，在筛选条件落后或者回来是没有区别的，极端的，在这两种查询时间的准备，只有在不使用也没有什么问题。作为一个结果，之间的差异在过滤和筛选，只有外连接，最常用的左连接和右连接。
下面的话不要多说，一起来看看详细的介绍：
请看一个包含两个表、结构和数据的示例
表主
表外
这两个表可以被视为存储用户信息。主要场所的主要信息，分机表所附加的信息，和两个表之间的关系是1到1，和身份特征作为对应关系的关键。现在我们需要屏幕上的所有用户的信息，并不是杭州的地址，结果需要包含主表的所有现场数据和外部表。
SELECT * FROM主左连接埃克斯顿main.id = ext.id地址<>杭州
闭上眼睛，用人脑来运行这个SQL，想象结果是什么。
当地址<>杭州筛选条件的查询结果后似乎我们预期不同的结果可以看出，该滤波器只似乎过滤掉分机表的相应记录，与主记录没被过滤掉，上面还标有红色的记录外的一个主要特征，加入相对于内连接是基于一个边桌。但是，基于它的左表可以忽略过滤条件，这太霸道了。
更改查询并将地址筛选器从哪里传送到哪里
SELECT * FROM主左连接分机上main.id = ext.id所在地址<>杭州
结果正如我们所预料的。
这个结果的差异据说来自于外部连接查询逻辑查询的各个阶段。
一般来说，外部连接的执行分为4个步骤。
1。首先，交叉连接到两个表（笛卡尔积）
2。应用过滤器
三.添加外部线
4。在滤波器的应用
对于不使用其上的过滤器的SQL，执行的整个过程如下
第一步是交叉连接到两个表中。结果如下：此步骤产生36条记录（此图显示不完整）。
第二步是应用过滤器。过滤器有两个条件，main.id = ext.id地址>的'杭州'，需要记录如下
这似乎是我们预期中的查询结果，但是在下面的步骤中，结果将被打乱。
第三步，添加外部行。外部连接的一个特性是它基于表的一个侧面，如果另一个表的表没有一个符合过滤条件的记录，则它被替换为null。
不是一种多余的感觉，因为这样
第四步，应用地方过滤器
在这个问题中，由于没有SQL过滤器，最后一步的结果是最终结果。
对于该地址在WHERE条件下过滤SQL，此步骤起到屏蔽所有不属于杭州的记录的作用。
通过上面的解释，它能够反映外连接的筛选条件和。如果开发人员能够理解细节上的差异，他们可以避免在编写SQL过程中出现许多莫名其妙的错误。
总结
以上就是本文的全部内容。希望本文的内容能给大家的学习或工作带来一定的帮助。如果有任何疑问，您可以留言交流，谢谢您的支持。