關(guān)于mysql?left?join?查詢慢時間長的踩坑總結(jié)
問題背景
兩張表一張是用戶表a(主鍵是int類型),一張是用戶具體信息表b(用戶表id字段是varchar類型)。
因?yàn)橐@示用戶及用戶信息,所以需要關(guān)聯(lián)查詢,但發(fā)現(xiàn)left join后查詢緩慢,耗時太長。用戶表數(shù)據(jù)2萬左右。
問題分析及處理
1、EXPLAIN 命令對 SELECT 語句進(jìn)行分析
type 字段提供了判斷查詢是否高效的重要依據(jù)依據(jù). 通過 type 字段, 我們判斷此次查詢是 全表掃描 還是 索引掃描 等.
ALL: 表示全表掃描, 這個類型的查詢是性能最差的查詢之一.
通常來說, 我們的查詢不應(yīng)該出現(xiàn) ALL 類型的查詢, 因?yàn)檫@樣的查詢在數(shù)據(jù)量大的情況下, 對數(shù)據(jù)庫的性能是巨大的災(zāi)難. 如一個查詢是 ALL 類型查詢, 那么一般來說可以對相應(yīng)的字段添加索引來避免.
2、新增索引
因?yàn)榘l(fā)現(xiàn)表b字段之前并沒有建索引。
alter table a add index idx_mbrID (mbrID);
再次Explain分析
發(fā)現(xiàn)type變?yōu)榱藃ef,根據(jù)不同的 type 類型的性能關(guān)系(
ALL < index < range ~ index_merge < ref < eq_ref < const < system
)比較后感覺可以了,于是執(zhí)行查詢。
3、修改索引字段類型一致
執(zhí)行查詢后發(fā)現(xiàn)執(zhí)行速度并未優(yōu)化,仔細(xì)看之前同事設(shè)計(jì)的表,發(fā)現(xiàn)索引類型字段不一致,于是修改為varchar 為int后再次查詢發(fā)現(xiàn)查詢速度明顯提升。
即使之前java代碼里面寫的string,數(shù)據(jù)庫改為int目前測試可正常使用
渣渣總結(jié)
解決完問題后,翻起了開發(fā)手冊,發(fā)現(xiàn)索引規(guī)約明確強(qiáng)制join時數(shù)據(jù)類型必須一致,被關(guān)聯(lián)字段必須有索引?。?!
關(guān)于Explain用法參考
http://www.dbjr.com.cn/article/167406.htm
以上為個人經(jīng)驗(yàn),希望能給大家一個參考,也希望大家多多支持腳本之家。
相關(guān)文章
解析mysql數(shù)據(jù)庫還原錯誤:(mysql Error Code: 1005 errno 121)
本篇文章是對mysql數(shù)據(jù)庫還原錯誤:(mysql Error Code: 1005 errno 121)的解決方法進(jìn)行了詳細(xì)的分析介紹,需要的朋友參考下2013-06-06Win10下免安裝版MySQL8.0.16的安裝和配置教程圖解
這篇文章主要介紹了Win10下免安裝版MySQL8.0.16的安裝和配置 ,本文通過圖文并茂的形式給大家介紹的非常詳細(xì),具有一定的參考解決價值,需要的朋友可以參考下2019-06-06MySQL因配置過大內(nèi)存導(dǎo)致無法啟動的解決方法
這篇文章主要給大家介紹了關(guān)于MySQL因配置過大內(nèi)存導(dǎo)致無法啟動的解決方法,文中給出了詳細(xì)的解決示例代碼,對遇到這個問題的朋友們具有一定的參考學(xué)習(xí)價值,需要的朋友們下面來一起看看吧。2017-06-06MySQL中count()和count(1)有何區(qū)別以及哪個性能最好詳解
count是一個函數(shù),用來統(tǒng)計(jì)數(shù)據(jù),但是count函數(shù)傳入的參數(shù)有很多種,比如count(1)、count(*)、count(字段)等,下面這篇文章主要給大家介紹了關(guān)于MySQL中count()和count(1)有何區(qū)別以及哪個性能最好的相關(guān)資料,需要的朋友可以參考下2022-08-08MySQL Aborted connection告警日志的分析
這篇文章主要介紹了MySQL Aborted connection告警日志的分析,幫助大家更好的理解和學(xué)習(xí)MySQL,感興趣的朋友可以了解下2020-08-08