今天看一條 SQL 的執(zhí)行計(jì)劃時(shí)候 type 為 index
還以為 left join 的時(shí)候走了索引柠新。
但是 rows 的數(shù)據(jù)顯示是走了全表掃描馒吴。奇怪了，而且該字段也是建了索引。
后來找到原因是 兩個(gè)表 join 的字段 字符集不是同一個(gè)類型颤诀，所以導(dǎo)致這個(gè)性能問題谜慌。
統(tǒng)一了 字符集后然想，果真性能就上來了。
再EXPLAIN 看了看
type 的類型 變?yōu)榱?eq_ref
官網(wǎng)查了查 原來 index 和 all 差不多（好久沒看忘記了）欣范。
Extra 與 type 詳細(xì)說明
Distinct:一旦MYSQL找到了與行相聯(lián)合匹配的行,就不再搜索了
Not exists: MYSQL優(yōu)化了LEFT JOIN,一旦它找到了匹配LEFT JOIN標(biāo)準(zhǔn)的行,就不再搜索了
Range checked for each Record（index map:#）:沒有找到理想的索引,因此對于從前面表中來的每一個(gè)行組合,MYSQL檢查使用哪個(gè)索引,并用它來從表中返回行变泄。這是使用索引的最慢的連接之一
Using filesort: 看到這個(gè)的時(shí)候,查詢就需要優(yōu)化了。MYSQL需要進(jìn)行額外的步驟來發(fā)現(xiàn)如何對返回的行排序恼琼。它根據(jù)連接類型以及存儲(chǔ)排序鍵值和匹配條件的全部行的行指針來排序全部行
Using index: 列數(shù)據(jù)是從僅僅使用了索引中的信息而沒有讀取實(shí)際的行動(dòng)的表返回的,這發(fā)生在對表的全部的請求列都是同一個(gè)索引的部分的時(shí)候
Using temporary 看到這個(gè)的時(shí)候,查詢需要優(yōu)化了妨蛹。這里,MYSQL需要?jiǎng)?chuàng)建一個(gè)臨時(shí)表來存儲(chǔ)結(jié)果,這通常發(fā)生在對不同的列集進(jìn)行ORDER BY上,而不是GROUP BY上
Where used 使用了WHERE從句來限制哪些行將與下一張表匹配或者是返回給用戶。如果不想返回表中的全部行,并且連接類型ALL或index,這就會(huì)發(fā)生,或者是查詢有問題不同連接類型的解釋（按照效率高低的順序排序
system 表只有一行：system表晴竞。這是const連接類型的特殊情況
const:表中的一個(gè)記錄的最大值能夠匹配這個(gè)查詢（索引可以是主鍵或惟一索引）蛙卤。因?yàn)橹挥幸恍?這個(gè)值實(shí)際就是常數(shù),因?yàn)镸YSQL先讀這個(gè)值然后把它當(dāng)做常數(shù)來對待
eq_ref:在連接中,MYSQL在查詢時(shí),從前面的表中,對每一個(gè)記錄的聯(lián)合都從表中讀取一個(gè)記錄,它在查詢使用了索引為主鍵或惟一鍵的全部時(shí)使用
ref:這個(gè)連接類型只有在查詢使用了不是惟一或主鍵的鍵或者是這些類型的部分（比如,利用最左邊前綴）時(shí)發(fā)生。對于之前的表的每一個(gè)行聯(lián)合,全部記錄都將從表中讀出。這個(gè)類型嚴(yán)重依賴于根據(jù)索引匹配的記錄多少—越少越好+
range:這個(gè)連接類型使用索引返回一個(gè)范圍中的行,比如使用>或<查找東西時(shí)發(fā)生的情況+
index: 這個(gè)連接類型對前面的表中的每一個(gè)記錄聯(lián)合進(jìn)行完全掃描（比ALL更好,因?yàn)樗饕话阈∮诒頂?shù)據(jù)）+
ALL:這個(gè)連接類型對于前面的每一個(gè)記錄聯(lián)合進(jìn)行完全掃描,這一般比較糟糕,應(yīng)該盡量避免
參考地址
https://dev.mysql.com/doc/refman/5.7/en/explain-output.html#explain-join-types
https://blog.csdn.net/zhoudapeng8023/article/details/67634653
https://www.kancloud.cn/thinkphp/mysql-design-optimalize/39319
