運營組的同事最近提出一個需求,希望可以統(tǒng)計出用系統(tǒng)用戶及訂單情況,于是乎我們很想當然的寫出了一個統(tǒng)計SQL,用戶表user和行程表直接join,并且針對行程做了group,但SQL執(zhí)行速度出奇的慢。
10年積累的成都網站建設、成都做網站經驗,可以快速應對客戶對網站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網絡服務。我雖然不認識你,你也不認識我。但先網站設計后付款的網站建設流程,更有雜多免費網站建設讓你可以放心的選擇與我們合作。
explain select users.`mobile_num`, concat(users.`lastName` ,users.`firstName`) as userName, users.`company`,
(case `users`.`idPhotoCheckStatus` when '2' then '已認證' when '3' then '已駁回' else '待認證' end) as `idPhotoCheckStatus`,
(case `users`.`driverLicenseCheckStatus` when '2' then '已認證' when '3' then '已駁回' else '待認證' end) as `driverLicenseCheckStatus`,
(case `users`.`companyCheckStatus` when '2' then '已認證' when '3' then '已駁回' else '待認證' end) as `companyCheckStatus`,
(case `users`.`unionCheckStatus` when '2' then '已認證' when '3' then '已駁回' else '待認證' end) as `unionCheckStatus`,
count(passenger_trip.id) as ptrip_num
from users
left join passenger_trip on passenger_trip.userId = users.id and passenger_trip.status != 'cancel'
left join driver_trip on driver_trip.`userId`=users.`id` and driver_trip.`status` != 'cancel'
where company != '本公司名' and company != '本公司昵稱'
當時的第一反應是數(shù)據(jù)庫掛住了,因為用戶表的數(shù)據(jù)量10W左右,行程表的數(shù)據(jù)也是10W左右,不可能這么慢!通過explain查看分析計劃,并且查看過關聯(lián)字段的索引情況,發(fā)現(xiàn)這是一個最常見的關聯(lián)查詢,當然是通過join實現(xiàn)。
轉而一想,10W*10W,經過笛卡爾集之后,這不是百億級的數(shù)據(jù)篩選嗎?!于是換了一種寫法進行嘗試。
explain select users.`mobile_num`, concat(users.`lastName` ,users.`firstName`) as userName, users.`company`,
(case `users`.`idPhotoCheckStatus` when '2' then '已認證' when '3' then '已駁回' else '待認證' end) as `idPhotoCheckStatus`,
(case `users`.`driverLicenseCheckStatus` when '2' then '已認證' when '3' then '已駁回' else '待認證' end) as `driverLicenseCheckStatus`,
(case `users`.`companyCheckStatus` when '2' then '已認證' when '3' then '已駁回' else '待認證' end) as `companyCheckStatus`,
(case `users`.`unionCheckStatus` when '2' then '已認證' when '3' then '已駁回' else '待認證' end) as `unionCheckStatus`,
(select count(passenger_trip.id) from passenger_trip where passenger_trip.userId = users.id and passenger_trip.status != 'cancel') as ptrip_num,
(select count(driver_trip.id) from driver_trip where driver_trip.userId = users.id and driver_trip.status != 'cancel') as dtrip_num
from users
where company != '本公司名' and company != '公司昵稱'
這樣的效果居然比直接join快了N倍,執(zhí)行速度從未知到10秒內返回,查看執(zhí)行計劃:
進一步調整SQL進行嘗試:
explain select users.`mobile_num`, concat(users.`lastName` ,users.`firstName`) as userName, users.`company`,
(case `users`.`idPhotoCheckStatus` when '2' then '已認證' when '3' then '已駁回' else '待認證' end) as `idPhotoCheckStatus`,
(case `users`.`driverLicenseCheckStatus` when '2' then '已認證' when '3' then '已駁回' else '待認證' end) as `driverLicenseCheckStatus`,
(case `users`.`companyCheckStatus` when '2' then '已認證' when '3' then '已駁回' else '待認證' end) as `companyCheckStatus`,
(case `users`.`unionCheckStatus` when '2' then '已認證' when '3' then '已駁回' else '待認證' end) as `unionCheckStatus`,
ptrip_num, dtrip_num
from users
left join
(select count(passenger_trip.id) as ptrip_num, passenger_trip.`userId` from passenger_trip where passenger_trip.status != 'cancel' group by passenger_trip.`userId` ) as ptrip
on ptrip.userId = users.id
left join
(select count(driver_trip.id) as dtrip_num, driver_trip.`userId` from driver_trip where driver_trip.status != 'cancel' group by driver_trip.`userId` ) as dtrip
on dtrip.userId = users.id
where company != '本公司名' and company != '公司昵稱'
居然5秒內返回,這才是正常的預期,10W級的數(shù)據(jù)篩選,應該是幾秒內返回的!
出現(xiàn)這種差別的原因,其實很簡單,SQL語句執(zhí)行的時候是有一定順序的。
第一種寫法,直接join的結果,就是在100億條數(shù)據(jù)中進行篩選;
后面兩種則是優(yōu)先執(zhí)行子查詢,完成10W級別的查詢,再進行一次主表10W級的關聯(lián)查詢,所以數(shù)量級明顯少于第一種寫法。
文章名稱:SQL關聯(lián)查詢直接join和子查詢的區(qū)別
URL網址:http://muchs.cn/article12/pidjgc.html
成都網站建設公司_創(chuàng)新互聯(lián),為您提供外貿建站、面包屑導航、服務器托管、營銷型網站建設、外貿網站建設、網站維護
聲明:本網站發(fā)布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)