您好,登錄后才能下訂單哦!
子查詢我相信大部分人都寫過,但是昨天遇到一個比較坑的問題,由于有較好的備份,很短時間就恢復了誤操作數據,但是這個問題值得分享。
首先建立如下測試表:
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');
現在我們執行如下查詢操作:
SELECT FROM student WHERE id IN (SELECT id FROM course)
這個結果很明顯,多了一條。而在昨天,我們開發寫的是個update 操作,也是就:update student set name='特腿' where id in (select id from course) 本來更新1000條的數據,開發直接誤更新了40萬條。
仔細排查后,發現剛才兩條sql發現 course 中根本就不存在id列,那么剛才那兩條sql為啥沒有拋出id報錯,而是直接全表匹配了?
我們 desc extended 看看優化器究竟干了什么?
DESC EXTENDED SELECT FROM student WHERE id IN (SELECT id FROM course)
SHOW WARNINGS
第一行1276 大意是說第二個查詢中的 id 列在第一個表中被解析到
第二行就是解析器解析后的sql,我們貼出來看看
SELECT yhtest
.student
.id
AS id
,yhtest
.student
.name
AS name
FROMyhtest
.student
semi
JOIN (yhtest
.course
)
WHERE (yhtest
.student
.id
= yhtest
.student
.id
)
也就是說我們這個子查詢中的id 列被解析為了主表的id 列,這樣,where 條件是一個恒成立的條件,所以導致我們的查詢過結果是a表的全表結果,而這也是這樣的查詢不拋錯的原因。
子查詢中的字段,首先會在子查詢中查找,1)如果子查詢中沒該字段,則會去外層主表查找,如果能找到,也不會拋錯! 2)如果子查詢和主表中都沒有該字段,則會拋錯。
這其實是一個比較不理想的結果,如果我們無意中錯誤是update操作,那么這個結果太糟糕。
這個我們提了兩個醒:
1)做數據庫操作之前,最好都備份
2)平時寫sql的時候,子查詢盡量都寫成表關聯的形式,表關聯形式,如果出現這種錯誤,會直接拋出錯誤。子查詢形式,雖然好懂,一目了然,但是性能一般不大好,再一個,如果掉進了以上這種誤更新坑中......
3)在不同版本的數據庫對于子查詢的優化操作也是不盡相同,性能差異在不同版本之間還是比較明顯的。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。