我們公司是做汽車服務(wù)行業(yè)SCRM門店管理系統(tǒng)的，其中一個(gè)功能是查出該門店的所有會(huì)員與之對應(yīng)的車輛。有三張表，核心字段如下：

需求：查出某個(gè)門店下的所有會(huì)員與車輛列表（會(huì)員姓名，車輛品牌，車牌號(hào)，車標(biāo)logo）

比如store_id=1的本店下的所有會(huì)員車輛列表，每次只取出20條：

第一次優(yōu)化

分析：需要三張表相連，其中一個(gè)會(huì)員可能有多輛車，所以車輛表必然比會(huì)員表的記錄多，而會(huì)員表可通過門店store_id只篩選出本店的會(huì)員。由此可見，先查出本門店會(huì)員再與車輛表相連，再與車品牌表相連，在會(huì)員表的storeid和車輛表的mid和車品牌表brand_code上建索引，這種連接順序，IO成本比較小，是一種不錯(cuò)的方案。

比如

member_base 1000條

where store_id走索引之后只真正取出100條

連接 car_base 1500條，走mid索引真正取出120條

連接 car_brand 50條 走id索引 取出1條

總IO成本為100+120+1=230

推算其他幾種連接順序方案與這種對比，IO成本都不如這種少

故使用left join 強(qiáng)制左表連右表：

select name,brand_name,cpai,brand_logo

from member_base as m left join car_base as c on m.id=c.mid

left join car_brand as b on c.brand_code=b.id

where m.store_id=? limit 20 ;

(mysql查詢優(yōu)化器會(huì)自動(dòng)先where篩選出member_base會(huì)員表store_id本門店的會(huì)員，再join)

第二次優(yōu)化

有時(shí)候?yàn)榱俗非蟾玫牟樵冃?#xff0c;可在車輛表甚至?xí)T表做字段冗余，減少join連表的。

比如在車輛表，添加需要查出的brand_name和brand_logo字段，這樣我們只需要會(huì)員表與車輛表總共兩張表相連即可。(sql省略)

第三次優(yōu)化

由于我們每次只取出limit 20條的記錄，我們首次在查會(huì)員表的時(shí)候，一般該門店的會(huì)員不都只有20條記錄這么少，我記得系統(tǒng)中很多門店的會(huì)員數(shù)量都在1千條以上，那么這個(gè)時(shí)候，再與車輛表相連的時(shí)候，會(huì)把會(huì)員表每一條記錄的id都在整個(gè)車輛表查一遍，共查了1000次，這是非常不劃算的。(sql語句的執(zhí)行順序通常是先 join on 后 where 后 group by 后 統(tǒng)計(jì)函數(shù) 后 having 后 order by 最后才執(zhí)行l(wèi)imit )

解決方案

先在會(huì)員表取出門店的20條記錄會(huì)員，再與車輛表join

select * from (select * from member_base where store_id=? limit 20) as m left join car_base as c on m.id=c.mid

最終只在車輛表查詢20次即可。

總結(jié)

以上是生活随笔為你收集整理的sql优化中in关键字_工作中遇到的一个SQL优化问题与解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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