對(duì)于生產(chǎn)庫中遇到mysql的子查詢示例詳細(xì)說明
發(fā)表時(shí)間:2023-07-22 來源:明輝站整理相關(guān)軟件相關(guān)文章人氣:
[摘要]使用過oracle或者其他關(guān)系數(shù)據(jù)庫的DBA或者開發(fā)人員都有這樣的經(jīng)驗(yàn),在子查詢上都認(rèn)為數(shù)據(jù)庫已經(jīng)做過優(yōu)化,能夠很好的選擇驅(qū)動(dòng)表執(zhí)行,然后在把該經(jīng)驗(yàn)移植到mysql數(shù)據(jù)庫上,但是不幸的是,mysql...
使用過oracle或者其他關(guān)系數(shù)據(jù)庫的DBA或者開發(fā)人員都有這樣的經(jīng)驗(yàn),在子查詢上都認(rèn)為數(shù)據(jù)庫已經(jīng)做過優(yōu)化,能夠很好的選擇驅(qū)動(dòng)表執(zhí)行,然后在把該經(jīng)驗(yàn)移植到mysql數(shù)據(jù)庫上,但是不幸的是,mysql在子查詢的處理上有可能會(huì)讓你大失所望,在我們的生產(chǎn)系統(tǒng)上就由于碰到了這個(gè)問題:
select i_id, sum(i_sell) as i_sell
from table_data
where i_id in (select i_id from table_data where Gmt_create >= ‘2011-10-07 00:00:00’)
group by i_id;
(備注:sql的業(yè)務(wù)邏輯可以打個(gè)比方:先查詢出10-07號(hào)新賣出的100本書,然后在查詢這新賣出的100本書在全年的銷量情況)。
這條sql之所以出現(xiàn)的性能問題在于mysql優(yōu)化器在處理子查詢的弱點(diǎn),mysql優(yōu)化器在處理子查詢的時(shí)候,會(huì)將將子查詢改寫。通常情況下,我們希望由內(nèi)到外,先完成子查詢的結(jié)果,然后在用子查詢來驅(qū)動(dòng)外查詢的表,完成查詢;但是mysql處理為將會(huì)先掃描外面表中的所有數(shù)據(jù),每條數(shù)據(jù)將會(huì)傳到子查詢中與子查詢關(guān)聯(lián),如果外表很大的話,那么性能上將會(huì)出現(xiàn)問題;
針對(duì)上面的查詢,由于table_data這張表的數(shù)據(jù)有70W的數(shù)據(jù),同時(shí)子查詢中的數(shù)據(jù)較多,有大量是重復(fù)的,這樣就需要關(guān)聯(lián)近70W次,大量的關(guān)聯(lián)導(dǎo)致這條sql執(zhí)行了幾個(gè)小時(shí)也沒有執(zhí)行完成,所以我們需要改寫sql:
SELECT t2.i_id, SUM(t2.i_sell) AS sold
FROM (SELECT distinct i_id FROM table_data
WHERE gmt_create >= ‘2011-10-07 00:00:00’) t1, table_data t2
WHERE t1.i_id = t2.i_id GROUP BY t2.i_id;
我們將子查詢改為了關(guān)聯(lián),同時(shí)在子查詢中加上distinct,減少t1關(guān)聯(lián)t2的次數(shù);
改造后,sql的執(zhí)行時(shí)間降到100ms以內(nèi)。
以上就是關(guān)于生產(chǎn)庫中遇到mysql的子查詢示例詳解的詳細(xì)內(nèi)容,更多請(qǐng)關(guān)注php中文網(wǎng)其它相關(guān)文章!
學(xué)習(xí)教程快速掌握從入門到精通的SQL知識(shí)。