本篇文章給大家?guī)?lái)了關(guān)于mysql的相關(guān)知識(shí)，其中主要介紹了關(guān)于left join查詢(xún)慢時(shí)間長(zhǎng)的踩坑總結(jié)，包括了EXPLAIN命令對(duì)SELECT語(yǔ)句進(jìn)行分析，下面一起來(lái)看一下，希望對(duì)大家有幫助。

程序員必備接口測(cè)試調(diào)試工具：立即使用
Apipost = Postman + Swagger + Mock + Jmeter
Api設(shè)計(jì)、調(diào)試、文檔、自動(dòng)化測(cè)試工具
后端、前端、測(cè)試，同時(shí)在線協(xié)作，內(nèi)容實(shí)時(shí)同步

推薦學(xué)習(xí)：mysql視頻教程

問(wèn)題背景

兩張表一張是用戶(hù)表a(主鍵是int類(lèi)型)，一張是用戶(hù)具體信息表b（用戶(hù)表id字段是varchar類(lèi)型）。

因?yàn)橐@示用戶(hù)及用戶(hù)信息，所以需要關(guān)聯(lián)查詢(xún)，但發(fā)現(xiàn)left join后查詢(xún)緩慢，耗時(shí)太長(zhǎng)。用戶(hù)表數(shù)據(jù)2萬(wàn)左右。

問(wèn)題分析及處理

1、EXPLAIN 命令對(duì) SELECT 語(yǔ)句進(jìn)行分析

type 字段提供了判斷查詢(xún)是否高效的重要依據(jù)依據(jù). 通過(guò) type 字段, 我們判斷此次查詢(xún)是 全表掃描 還是 索引掃描 等.

ALL: 表示全表掃描, 這個(gè)類(lèi)型的查詢(xún)是性能最差的查詢(xún)之一.

通常來(lái)說(shuō), 我們的查詢(xún)不應(yīng)該出現(xiàn) ALL 類(lèi)型的查詢(xún), 因?yàn)檫@樣的查詢(xún)?cè)跀?shù)據(jù)量大的情況下, 對(duì)數(shù)據(jù)庫(kù)的性能是巨大的災(zāi)難. 如一個(gè)查詢(xún)是 ALL 類(lèi)型查詢(xún), 那么一般來(lái)說(shuō)可以對(duì)相應(yīng)的字段添加索引來(lái)避免.

2、新增索引

因?yàn)榘l(fā)現(xiàn)表b字段之前并沒(méi)有建索引。

alter table a add index idx_mbrID (mbrID);

再次Explain分析

發(fā)現(xiàn)type變?yōu)榱藃ef，根據(jù)不同的 type 類(lèi)型的性能關(guān)系(

ALL < index < range ~ index_merge < ref < eq_ref < const < system

)比較后感覺(jué)可以了，于是執(zhí)行查詢(xún)。

3、修改索引字段類(lèi)型一致

執(zhí)行查詢(xún)后發(fā)現(xiàn)執(zhí)行速度并未優(yōu)化，仔細(xì)看之前同事設(shè)計(jì)的表，發(fā)現(xiàn)索引類(lèi)型字段不一致，于是修改為varchar 為int后再次查詢(xún)發(fā)現(xiàn)查詢(xún)速度明顯提升。

即使之前java代碼里面寫(xiě)的string，數(shù)據(jù)庫(kù)改為int目前測(cè)試可正常使用

總結(jié)

解決完問(wèn)題后，翻起了開(kāi)發(fā)手冊(cè)，發(fā)現(xiàn)索引規(guī)約明確強(qiáng)制join時(shí)數(shù)據(jù)類(lèi)型必須一致，被關(guān)聯(lián)字段必須有索引?。?！

推薦學(xué)習(xí)：mysql視頻教程