共計(jì) 841 個(gè)字符，預(yù)計(jì)需要花費(fèi) 3 分鐘才能閱讀完成。

本篇內(nèi)容主要講解“mysql left join 查詢(xún)慢時(shí)間長(zhǎng)問(wèn)題怎么解決”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓丸趣 TV 小編來(lái)帶大家學(xué)習(xí)“mysql left join 查詢(xún)慢時(shí)間長(zhǎng)問(wèn)題怎么解決”吧!

問(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);

登錄后復(fù)制

再次 Explain 分析

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

ALL   index   range ~ index_merge   ref   eq_ref   const   system

登錄后復(fù)制

) 比較后感覺(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è)試可正常使用

到此，相信大家對(duì)“mysql left join 查詢(xún)慢時(shí)間長(zhǎng)問(wèn)題怎么解決”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是丸趣 TV 網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢(xún)，關(guān)注我們，繼續(xù)學(xué)習(xí)！