腳本之家服務器常用軟件

快捷導航

MySQL中多個left?join?on關聯(lián)條件的順序說明

更新時間：2022年11月16日 11:02:11 作者：p7+

這篇文章主要介紹了MySQL中多個left?join?on關聯(lián)條件的順序說明，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教

MySQL多個left join on關聯(lián)條件順序

注意：下面的案例特別重要！請重視！SQL有點長，但確實是干貨！

結論

如果存在多個left join on，請注意on后面的條件與哪個表關聯(lián)。這一條統(tǒng)計的SQL很重要！例如表A，B，C，A left join B on A.x = B.x left join C on A.x = C.x，B和C的都要和A建立關聯(lián)，B和C之間是沒有任何數(shù)據(jù)上的關系。

但是如果把A.x = C.x改成B.x = C.x，那么B和C的表數(shù)據(jù)先建立關聯(lián)并過濾數(shù)據(jù)，再與A表數(shù)據(jù)進行關聯(lián)，這樣可能會出現(xiàn)數(shù)據(jù)丟失！

案例

有一張分數(shù)表，表字段有日期、姓名、語文得分和數(shù)學得分等，請統(tǒng)計每個日期中，語文最高得分的姓名和分數(shù)，數(shù)學最低得分的姓名和分數(shù)。

思路：過濾出所有日期 left join 篩選語文 on … left join 數(shù)學得分 on …

正確的SQL：

SELECT
	* 
FROM
	( SELECT report_date reportDate FROM tb_more_left_join mlj GROUP BY mlj.report_date ) mix
	LEFT JOIN (
SELECT
	mlj.report_date maxReportDate,
	GROUP_CONCAT( mlj.user_name ) maxUserNames,
	a.maxScore 
FROM
	tb_more_left_join mlj
	LEFT JOIN ( SELECT report_date, MAX( chinese_score ) maxScore FROM tb_more_left_join mlj GROUP BY mlj.report_date ORDER BY NULL ) a ON mlj.report_date = a.report_date 
WHERE
	mlj.chinese_score = a.maxScore 
GROUP BY
	mlj.report_date 
	) mx ON mix.reportDate = mx.maxReportDate
	LEFT JOIN (
SELECT
	mlj.report_date minReportDate,
	GROUP_CONCAT( mlj.user_name ) minUserNames,
	a.minScore 
FROM
	tb_more_left_join mlj
	LEFT JOIN ( SELECT report_date, MIN( math_score ) minScore FROM tb_more_left_join mlj GROUP BY mlj.report_date ORDER BY NULL ) a ON mlj.report_date = a.report_date 
WHERE
	mlj.math_score = a.minScore 
GROUP BY
	mlj.report_date 
	) mn ON mix.reportDate = mn.minReportDate

正確結果：

錯誤的SQL：

把正確SQL中最后一個on條件改為mx.maxReportDate = mn.minReportDate，注意，是把mix.reportDate改為了mx.maxReportDate。

錯誤結果：

錯誤原因：

查詢語文最高成績時，沒有查到2019-12-01的數(shù)據(jù)
查詢數(shù)學最低成績時，使用on與語文最高成績關聯(lián)，因為沒有查到語文最高成績的日期，所以兩個表關聯(lián)時，數(shù)學最低成績即使有數(shù)據(jù)，也會因為語文最高成績無數(shù)據(jù)而被忽略。

SQL數(shù)據(jù)

CREATE TABLE `tb_more_left_join`  (
  `id` int(11) NOT NULL,
  `report_date` date NULL DEFAULT NULL,
  `user_name` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `math_score` int(255) NULL DEFAULT NULL,
  `chinese_score` int(255) NULL DEFAULT NULL,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic;

INSERT INTO `tb_more_left_join` VALUES (1, '2019-12-01', '盲僧', 70, NULL);
INSERT INTO `tb_more_left_join` VALUES (2, '2019-12-01', '薇恩', 100, NULL);
INSERT INTO `tb_more_left_join` VALUES (3, '2019-12-02', '趙信', 30, 60);
INSERT INTO `tb_more_left_join` VALUES (4, '2019-12-02', '琴女', NULL, 100);
INSERT INTO `tb_more_left_join` VALUES (5, '2019-12-03', '蠻王', 50, 100);
INSERT INTO `tb_more_left_join` VALUES (6, '2019-12-03', '艾希', 100, 100);
INSERT INTO `tb_more_left_join` VALUES (7, '2019-12-03', '亞索', 60, 90);

使用left join的on后查詢碰到的大坑

很多時候我們在使用 LEFT JOIN ...... ON .... 時，除了連接兩個表的字段條件外，我們往往還需要一些等值或者范圍等等類似的數(shù)據(jù)篩選條件。

那么對于初學者，往往會犯一個錯誤，就是想當然地認為， ON 后面的條件是逐一執(zhí)行的，因為沒有了解清楚 ON 后面接條件的規(guī)則。

是個什么樣的場景？

看實例講解：

userinfo 表：

（找兼職的人員名單信息表）

jobinfo表：

（兼職工作信息及職業(yè)要求表）

業(yè)務需求：

根據(jù)職業(yè)要求給找兼職的人員匹配上目前可以做的兼職，輸出數(shù)據(jù)條。

例如，李三是一個程序員，他迫于經(jīng)濟壓力，不得不向社會低頭，想找一些自己能做的兼職。

使用 WHERE

如果我們不用 left join ...... on ... , 僅僅使用 where，那么簡單寫下sql是：

SELECT * 
FROM userinfo AS u ,jobinfo AS j 
WHERE u.userProfession=j.professionRequire
AND j.professionRequire='程序員'

查詢出來的結果如下：

是我們需要的結果，可以看的，程序員李三能做的兼職有，送外賣或者當保安。

使用 LEFT JOIN ...... ON ......

初學者（罪過）寫的SQL ：

想當然地把篩選條件職業(yè)要求為 ‘ 程序員’ 直接 拼接在 ON 后面

SELECT * 
FROM userinfo AS u 
LEFT JOIN   
jobinfo AS j 
ON u.userProfession=j.professionRequire
AND j.professionRequire='程序員'

這樣地拼接篩選條件其實是達不到所想要的效果的，先來看看這樣的執(zhí)行結果：

可以看到查詢出來很多我們不想要的數(shù)據(jù)，為什么會這樣？

原因

因為如果直接把關聯(lián)表的篩選條件拼接在 ON 后，執(zhí)行的順序其實是：

將 jobinfo 表按照篩選條件 professionRequire='程序員' 執(zhí)行后作為子查詢，再執(zhí)行 LEFT JOIN ...... ON 。

也就是第一步變成了執(zhí)行 SELECT * FROM jobinfo AS j WHERE j.professionRequire='程序員'

然后再進行連接查詢，也就是

整個sql語句其實變成了：

SELECT * 
FROM userinfo AS u 
LEFT JOIN   
(SELECT *  FROM jobinfo  WHERE jobinfo.professionRequire='程序員') AS j 
ON 
u.userProfession=j.professionRequire

這樣查詢出來，顯然不是我們想要的結果。

那么我們在使用 LEFT JOIN ...... ON ...... 拼接篩選條件時，我們應該怎么做？

配合 WHERE 使用：

SELECT * 
FROM userinfo AS u 
LEFT JOIN   jobinfo AS j 
ON u.userProfession=j.professionRequire
WHERE j.professionRequire='程序員'

結果：

我們把篩選條件配合where去使用，執(zhí)行的邏輯就是：

先執(zhí)行LEFT JOIN ...... ON ...... 先將關聯(lián)兩個表之后的數(shù)據(jù)查詢出來；

再按照 professionRequire='程序員' 條件，進行數(shù)據(jù)篩選。

所以這是我們想要得到的結果。

這是一個使用 LEFT JOIN 的 ON 初學者很容易犯的錯誤，大家稍微注意點。

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

您可能感興趣的文章:

欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

MySQL中多個left?join?on關聯(lián)條件的順序說明

目錄

MySQL多個left join on關聯(lián)條件順序

結論

案例

SQL數(shù)據(jù)

使用left join的on后查詢碰到的大坑

使用 WHERE

使用 LEFT JOIN ...... ON ......

原因

相關文章

最新評論

大家感興趣的內容

最近更新的內容

常用在線小工具