子查詢我相信大部分人都寫過，但是昨天遇到一個(gè)比較坑的問題，由于有較好的備份，很短時(shí)間就恢復(fù)了誤操作數(shù)據(jù)，但是這個(gè)問題值得分享。
首先建立如下測試表：
CREATE TABLE course (
student_id INT(11),
course VARCHAR(20)
);
INSERT INTO course VALUES ('1', '測試1');
INSERT INTO course VALUES ('2', '測試2');
INSERT INTO course VALUES ('3', '測試3');

CREATE TABLE student (
id INT(11),
name VARCHAR(20)
) ;
INSERT INTO student VALUES ('1', 'jiate');
INSERT INTO student VALUES ('2', 'haoshen');
INSERT INTO student VALUES ('3', 'leishen');
INSERT INTO student VALUES ('4', 'tetui');

現(xiàn)在我們執(zhí)行如下查詢操作：
SELECT FROM student WHERE id IN (SELECT id FROM course)

這個(gè)結(jié)果很明顯，多了一條。而在昨天，我們開發(fā)寫的是個(gè)update 操作，也是就：update student set name='特腿' where id in (select id from course) 本來更新1000條的數(shù)據(jù)，開發(fā)直接誤更新了40萬條。
仔細(xì)排查后，發(fā)現(xiàn)剛才兩條sql發(fā)現(xiàn) course 中根本就不存在id列，那么剛才那兩條sql為啥沒有拋出id報(bào)錯(cuò)，而是直接全表匹配了？
我們 desc extended 看看優(yōu)化器究竟干了什么?
DESC EXTENDED SELECT FROM student WHERE id IN (SELECT id FROM course)

SHOW WARNINGS

第一行1276 大意是說第二個(gè)查詢中的 id 列在第一個(gè)表中被解析到
第二行就是解析器解析后的sql，我們貼出來看看
SELECT
yhtest.student.id AS id,
yhtest.student.name AS name
FROM
yhtest.student semi
JOIN (yhtest.course)
WHERE (
yhtest.student.id = yhtest.student.id
)

也就是說我們這個(gè)子查詢中的id 列被解析為了主表的id 列，這樣，where 條件是一個(gè)恒成立的條件，所以導(dǎo)致我們的查詢過結(jié)果是a表的全表結(jié)果，而這也是這樣的查詢不拋錯(cuò)的原因。
子查詢中的字段，首先會(huì)在子查詢中查找，1）如果子查詢中沒該字段，則會(huì)去外層主表查找，如果能找到，也不會(huì)拋錯(cuò)！ 2）如果子查詢和主表中都沒有該字段，則會(huì)拋錯(cuò)。
這其實(shí)是一個(gè)比較不理想的結(jié)果，如果我們無意中錯(cuò)誤是update操作，那么這個(gè)結(jié)果太糟糕。
這個(gè)我們提了兩個(gè)醒：
1）做數(shù)據(jù)庫操作之前，最好都備份
2）平時(shí)寫sql的時(shí)候，子查詢盡量都寫成表關(guān)聯(lián)的形式，表關(guān)聯(lián)形式，如果出現(xiàn)這種錯(cuò)誤，會(huì)直接拋出錯(cuò)誤。子查詢形式，雖然好懂，一目了然，但是性能一般不大好，再一個(gè)，如果掉進(jìn)了以上這種誤更新坑中......
3）在不同版本的數(shù)據(jù)庫對(duì)于子查詢的優(yōu)化操作也是不盡相同，性能差異在不同版本之間還是比較明顯的。

轉(zhuǎn)載于:https://blog.51cto.com/11286233/2059003

總結(jié)

以上是生活随笔為你收集整理的子查询更新操作的坑的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。