left join 的時間開銷類似於笛卡爾積，相當費時，如果關聯欄位是索引字段，可以減少時間複雜度，但是還是非常費時。
left 的優化：首先，mysql都是使用（nested loop ）迴圈套嵌的方式實現join，這裡包括兩個部分：驅動表結果集作為條件連線被驅動表x，被驅動表根據驅動表結果查詢資料集y。時間複雜度（x*y），這裡的第二部分是資料庫內部的操作，涉及io，cpu等的操作很少，而且可以使用索引優化。第一部分是表的連線，這裡是需要時間的，時間複雜度，cpu，io操作等都耗費比內部操作更多的時間。所以，以少的實際結果集（where篩選後）驅動大的結果集，大的結果集使用索引，這種方式能夠最大層度的減少時間複雜度。也就是永遠使用小的結果集驅動大的結果集。
這裡規定join連線單次總用時為m1，被驅動表一次查詢使用時間為m2;則總的查詢時間為：
x*m1+y*m2;這裡的m1大於m2則 x相對於y越小，結果越小;
b平衡樹的索引結構，三種索引的速度以及覆蓋範圍排序: 1覆蓋索引》= 2聚集索引》3非聚集索引。 1和2中大於的部分不是速度，而是適用範圍，1覆蓋索引能夠根據業務自定義，而2基本都是主鍵，適用性不強，但是覆蓋索引占用記憶體比較大，這個是乙個限制條件。
索引總共分為三種，聚集索引，非聚集索引，覆蓋索引
非聚集索引會先找到聚集索引的唯一主鍵，然後根據聚集索引查詢值，例外的是覆蓋索引（多列索引）：查詢列在索引列中，不需要再到聚集索引中查詢一遍。
沒有主鍵（聚集索引）的表加資料堆，資料堆是通過使用索引分配圖（iam）頁來維護的。當在資料堆上建立了非聚簇索引時，葉級中包含了指向資料頁的行識別符號。行識別符號指定記錄行的邏輯順序，由檔案id、頁號和行id組成
MySQL下LeftJoin的效能優化
今天遇到了乙個問題，有乙個select語句執行超慢，在加了index之後依然超慢。資料庫是mysql，表a中有資料4000條，表b中有資料14000條 select語句為select count from a left join b on a.id b.id 語句1 執行時間為30秒 如果將sele...
關於left join 查詢的乙個小誤區
兩個表 a b aid 顏色 類別 1 yy 紅色 1 2 dd 白色 2 bid 名稱 類別 1 dd 社保科 1 2 dd 勞務科 2 3 xx 保衛科 1 4 xx 資料室 2 5 yy 宣傳科 2 sql select a.a.顏色,b.名稱 from a left join b on a....
關於多表的leftJoin
建立表結構如下 create table x.a a1 int,a2 varchar 10 create table x.b b1 int,b2 varchar 10 create table x.c c1 int,c2 varchar 10 insert into x.a values 1 hah...