关于 MySQL LEFT JOIN 你可能需要了解的三点

ON 子句与 WHERE 子句的不同 一种更好地理解带有 WHERE ... IS NULL 子句的复杂匹配条件的简单方法

Matching-Conditions 与 Where-conditions 的不同

关于 “A LEFT JOIN B ON 条件表达式” 的一点提醒

ON 条件（“A LEFT JOIN B ON 条件表达式”中的ON）用来决定如何从B表中检索数据行。

如果B表中没有任何一行数据匹配ON的条件,将会额外生成一行所有列为NULL的数据

在匹配阶段WHERE子句的条件都不会被使用。仅在匹配阶段完成以后，WHERE子句条件才会被使用。它将从匹配阶段产生的数据中检索过滤。

让我们看一个LFET JOIN示例：

mysql> CREATE TABLE `product` ( `id` int(10) unsigned NOT NULL auto_increment, `amount` int(10) unsigned default NULL, PRIMARY KEY (`id`))

ENGINE=MyISAM AUTO_INCREMENT=5 DEFAULT CHARSET=latin1

mysql> CREATE TABLE `product_details` (`id` int(10) unsigned NOT NULL, `weight` int(10) unsigned default NULL, `exist` int(10) unsigned default NULL,

PRIMARY KEY (`id`)) ENGINE=MyISAM DEFAULT CHARSET=latin1

mysql> INSERT INTO product (id,amount) VALUES (1,100),(2,200),(3,300),(4,400);

Query OK, 4 rows affected (0.00 sec)

Records: 4 Duplicates: 0 Warnings: 0

mysql> INSERT INTO product_details (id,weight,exist) VALUES (2,22,0),(4,44,1),(5,55,0),(6,66,1);

Query OK, 4 rows affected (0.00 sec)

Records: 4 Duplicates: 0 Warnings: 0

mysql> SELECT * FROM product;

| id | amount |

| 1 |    100 |

| 2 |    200 |

| 3 |    300 |

| 4 |    400 |

4 rows in set (0.00 sec)

mysql> SELECT * FROM product_details;

| id | weight | exist |

| 2 |     22 |     0 |

| 4 |     44 |     1 |

| 5 |     55 |     0 |

| 6 |     66 |     1 |

4 rows in set (0.00 sec)

mysql> SELECT * FROM product LEFT JOIN product_details

       ON (product.id = product_details.id);

| id | amount | id   | weight | exist |

| 1 |    100 | NULL |   NULL | NULL |

| 2 |    200 |    2 |     22 |     0 |

| 3 |    300 | NULL |   NULL | NULL |

| 4 |    400 |    4 |     44 |     1 |

4 rows in set (0.00 sec)

ON 子句和 WHERE 子句有什么不同？

一个问题：下面两个查询的结果集有什么不同么？

1. SELECT * FROM product LEFT JOIN product_details ON (product.id = product_details.id) AND product_details.id=2;

2. SELECT * FROM product LEFT JOIN product_details ON (product.id = product_details.id) WHERE product_details.id=2;

用例子来理解最好不过了：

mysql> SELECT * FROM product LEFT JOIN product_details ON (product.id = product_details.id) AND product_details.id=2;

| id | amount | id   | weight | exist |

| 1 |    100 | NULL |   NULL | NULL |

| 2 |    200 |    2 |     22 |     0 |

| 3 |    300 | NULL |   NULL | NULL |

| 4 |    400 | NULL |   NULL | NULL |

4 rows in set (0.00 sec)

mysql> SELECT * FROM product LEFT JOIN product_details ON (product.id = product_details.id) WHERE product_details.id=2;

| id | amount | id | weight | exist |

| 2 | 200 | 2 | 22 | 0 |

1 row in set (0.01 sec)

第一条查询使用 ON 条件决定了从 LEFT JOIN的 product_details表中检索符合的所有数据行。

第二条查询做了简单的LEFT JOIN，然后使用 WHERE 子句从 LEFT JOIN的数据中过滤掉不符合条件的数据行。

再来看一些示例：

mysql> SELECT * FROM product LEFT JOIN product_details ON product.id = product_details.id AND product.amount=100;

| id | amount | id   | weight | exist |

| 1 |    100 | NULL |   NULL | NULL |

| 2 |    200 | NULL |   NULL | NULL |

| 3 |    300 | NULL |   NULL | NULL |

| 4 |    400 | NULL |   NULL | NULL |

4 rows in set (0.00 sec)

所有来自product表的数据行都被检索到了，但没有在product_details表中匹配到记录（product.id = product_details.id AND product.amount=100 条件并没有匹配到任何数据）

mysql> SELECT * FROM product LEFT JOIN product_details ON (product.id = product_details.id) AND product.amount=200;

| id | amount | id   | weight | exist |

| 1 |    100 | NULL |   NULL | NULL |

| 2 |    200 |    2 |     22 |     0 |

| 3 |    300 | NULL |   NULL | NULL |

| 4 |    400 | NULL |   NULL | NULL |

4 rows in set (0.01 sec)

同样，所有来自product表的数据行都被检索到了，有一条数据匹配到了。

使用 WHERE ... IS NULL子句的LEFT JOIN

当你使用WHERE ... IS NULL子句时会发生什么呢？

如前所述，WHERE 条件查询发生在匹配阶段之后，这意味着WHERE ... IS NULL子句将从匹配阶段后的数据中过滤掉不满足匹配条件的数据行。

纸面上看起来很清楚，但是当你在 ON子句中使用多个条件时就会感到困惑了。

我总结了一种简单的方式来理解上述情况：

将 IS NULL 作为否定匹配条件

使用!(A and B) == !A OR !B 逻辑判断

看看下面的示例：

mysql> SELECT a.* FROM product a LEFT JOIN product_details b ON a.id=b.id AND b.weight!=44 AND b.exist=0 WHERE b.id IS NULL;

| id | amount |

| 1 |    100 |

| 3 |    300 |

| 4 |    400 |

3 rows in set (0.00 sec)

让我们检查一下ON匹配子句：

1(a.id=b.id) AND (b.weight!=44) AND (b.exist=0)

我们可以把IS NULL子句看作是否定匹配条件。

这意味着我们将检索到以下行：

!( exist(b.id that equals to a.id) AND b.weight !=44 AND b.exist=0 )

!exist(b.id that equals to a.id) || !(b.weight !=44) || !(b.exist=0)

!exist(b.id that equals to a.id) || b.weight =44 || b.exist=1

就像在C语言中的逻辑 AND 和逻辑 OR表达式一样，其操作数是从左到右求值的。如果第一个参数做够判断操作结果，那么第二个参数便不会被计算求值（短路效果）

看看别的示例：

mysql> SELECT a.* FROM product a LEFT JOIN product_details b ON a.id=b.id AND b.weight!=44 AND b.exist=1 WHERE b.id IS NULL;

| id | amount |

| 1 |    100 |

| 2 |    200 |

| 3 |    300 |

| 4 |    400 |

4 rows in set (0.00 sec)

Matching-Conditions与Where-conditions之战

如果你吧基本的查询条件放在ON 子句中，把剩下的否定条件放在WHERE 子句中，那么你会获得相同的结果。

例如，你可以不这样写：

SELECT a.* FROM product a LEFT JOIN product_details b ON a.id=b.id AND b.weight!=44 AND b.exist=0 WHERE b.id IS NULL;

你可以这样写：

SELECT a.* FROM product a LEFT JOIN product_details b ON a.id=b.id WHERE b.id is null OR b.weight=44 OR b.exist=1;

mysql> SELECT a.* FROM product a LEFT JOIN product_details b ON a.id=b.id WHERE b.id is null OR b.weight=44 OR b.exist=1;

| id | amount |

| 1 |    100 |

| 3 |    300 |

| 4 |    400 |

3 rows in set (0.00 sec)

你可以不这样写：

SELECT a.* FROM product a LEFT JOIN product_details b ON a.id=b.id AND b.weight!=44 AND b.exist!=0 WHERE b.id IS NULL;

可以这样写：

SELECT a.* FROM product a LEFT JOIN product_details b ON a.id=b.id WHERE b.id is null OR b.weight=44 OR b.exist=0;

mysql> SELECT a.* FROM product a LEFT JOIN product_details b ON a.id=b.id WHERE b.id is null OR b.weight=44 OR b.exist=0;

| id | amount |

| 1 |    100 |

| 2 |    200 |

| 3 |    300 |

| 4 |    400 |

4 rows in set (0.00 sec)

这些查询真的效果一样？

如果你只需要第一个表中的数据的话，这些查询会返回相同的结果集。有一种情况就是，如果你从 LEFT JOIN的表中检索数据时，查询的结果就不同了。

如前所属，WHERE 子句是在匹配阶段之后用来过滤的。例如：

mysql> SELECT * FROM product a LEFT JOIN product_details b ON a.id=b.id AND b.weight!=44 AND b.exist=1 WHERE b.id is null;

| id | amount | id   | weight | exist |

| 1 |    100 | NULL |   NULL | NULL |

| 2 |    200 | NULL |   NULL | NULL |

| 3 |    300 | NULL |   NULL | NULL |

| 4 |    400 | NULL |   NULL | NULL |

4 rows in set (0.00 sec)

mysql> SELECT * FROM product a LEFT JOIN product_details b ON a.id=b.id WHERE b.id IS NULL OR b.weight=44 OR b.exist=0;

| id | amount | id   | weight | exist |

| 1 |    100 | NULL |   NULL | NULL |

| 2 |    200 |    2 |     22 |     0 |

| 3 |    300 | NULL |   NULL | NULL |

| 4 |    400 |    4 |     44 |     1 |

4 rows in set (0.00 sec)

总附注：

如果你使用LEFT JOIN来寻找在一些表中不存在的记录，你需要做下面的测试：WHERE 部分的col_name IS NULL(其中 col_name 列被定义为 NOT NULL)，MYSQL 在查询到一条匹配 LEFT JOIN条件后将停止搜索更多行（在一个特定的组合键下）。

From：http://www.oschina.net/question/89964_65912

人面猴
序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
沈念sama阅读 214,658评论 6赞 496
死咒
序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
沈念sama阅读 91,482评论 3赞 389
救了他两次的神仙让他今天三更去死
文/潘晓璐我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
开封第一讲书人阅读 160,213评论 0赞 350
道士缉凶录：失踪的卖姜人
文/不坏的土叔我叫张陵，是天一观的道长。经常有香客问我，道长，这世上最难降的妖魔是什么？我笑而不...
开封第一讲书人阅读 57,395评论 1赞 288
港岛之恋（遗憾婚礼）
正文为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
茶点故事阅读 66,487评论 6赞 386
恶毒庶女顶嫁案：这布局不是一般人想出来的
文/花漫我一把揭开白布。她就那样静静地躺着，像睡着了一般。火红的嫁衣衬着肌肤如雪。梳的纹丝不乱的头发上，一...
开封第一讲书人阅读 50,523评论 1赞 293
城市分裂传说
那天，我揣着相机与录音，去河边找鬼。笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。我是一名探鬼主播，决...
沈念sama阅读 39,525评论 3赞 414
双鸳鸯连环套：你想象不到人心有多黑
文/苍兰香墨我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
开封第一讲书人阅读 38,300评论 0赞 270
万荣杀人案实录
序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
沈念sama阅读 44,753评论 1赞 307
护林员之死
正文独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋以下内容为张勋视角年9月15日...
茶点故事阅读 37,048评论 2赞 330
白月光启示录
正文我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
茶点故事阅读 39,223评论 1赞 343
活死人
序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
沈念sama阅读 34,905评论 5赞 338
日本核电站爆炸内幕
正文年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
茶点故事阅读 40,541评论 3赞 322
男人毒药：我在死后第九天来索命
文/蒙蒙一、第九天我趴在偏房一处隐蔽的房顶上张望。院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
开封第一讲书人阅读 31,168评论 0赞 21
一桩弑父案，背后竟有这般阴谋
文/苍兰香墨我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。一阵脚步声响...
开封第一讲书人阅读 32,417评论 1赞 268
情欲美人皮
我被黑心中介骗来泰国打工，没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。一个月前我还...
沈念sama阅读 47,094评论 2赞 365
代替公主和亲
正文我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
茶点故事阅读 44,088评论 2赞 352

关于 MySQL LEFT JOIN 你可能需要了解的三点

推荐阅读更多精彩内容