您好,登錄后才能下訂單哦!
MySQL的Join到底能不能用
經常聽到2種觀點:
其實對于上面的觀點一定程度上是正確的,但不是完全正確。但之所以流傳這么廣,主要還是沒有搞清楚實際狀態,而根據實際使用中總結出來的一些模糊規律。只有了解的MySQL的Join實際執行方式,就會知道上面2種觀點是一種模糊的規律,這種規律并不能指導我們實際開發。下面就說說MySQL的實際join執行方式。
join可以說一種集合的運算,比如left join,right join,inner join,full join,outer join,cross join等,這些集合間的計算關系對應在高中數學集合里面的交集,并集,補集,全集等。但在實際的代碼中,join運算基本上是通過多層循環來實現的。
舉一個例子,假設有t1,t2兩張表,表結構分別如下:
createtablet1(
idintnotnullAUTO_INCREMENT,
usernamevarchar(20)notnulldefault'',
ageintnotnulldefault0,
PRIMARYkey(`id`)
)ENGINE=INNODBDEFAULTCHARSET=UTF8MB4;
createtablet2(
idintnotnullauto_increment,
usernamevarchar(20)notnulldefault'',
scoreintnotnulldefalut0,
primarykey(`id`)
))ENGINE=INNODBDEFAULTCHARSET=UTF8MB4;
假設t1有100條數據,t2表有200條數
查詢sql為:
selectt1.*,t2.*fromt1leftjoint2on(t1.username=t2.username)
那么這條SQL的執行步驟如下:
基本上先遍歷t,1,然后根據t1中的每行數據中的username,去表t2中查找滿足條件的記錄。基本就是2層循環。
從上面可以看出,join本質是循環,這里的開銷如下:
從上面的步驟可以看出,優化方向:
優化的基本方法:
Batched Key Access Join 這個是 Index Nested Join上做的優化,因為回表的存在,隨機操作io也很耗費性能,這個算法的核心在于通過輔助索引去查找時,將得到的主鍵進行排序,然后按照主鍵遞增的順序進行查找,對磁盤的讀接近順序讀,從而優化性能
從上面的分析我們可以看到,用Join還是可行的,只要性能可控且在接受范圍內,還是能減少代碼復雜度的。需要避免的是join的表沒有索引,不然這樣的SQL發線上是災難性的。
Join還是可以大膽的使用,只要把握好幾個原則:
盡量讓join的列是索引列,而且最好是類型相同,盡可能是主鍵索引
盡量將小表做驅動表(這一點MySQL在5.6某個版本后能自動完成)
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。