導讀:2SEO優化嵌套查詢糟糕的優化 在上面我提到過，不考慮特殊的情況，聯表查詢要比嵌套查詢更有效。盡管兩條查詢表達的是同樣的意思，盡管你的計劃是告訴服務器要做什么，然后讓它決定網站建設多少錢網站推廣優化seo。

嵌套查詢糟糕的優化 在上面我提到過，不考慮特殊的情況，聯表查詢要比嵌套查詢更有效。盡管兩條查詢表達的是同樣的意思，盡管你的計劃是告訴服務器要做什么，然后讓它決定怎么做，但有時候你非得告訴它改怎么做。否則優化器可能會做傻事。我最近就碰到這樣的情況。這幾個表是三層分級關系：category, subcategory和item。有幾千條記錄在category表，幾百條記錄在subcategory表，以及幾百萬條在item表。你可以忽略category表了，我只是交代一下背景，以下查詢語句都不涉及到它。這是創建表的語句：   [sql]  復制代碼 代碼如下:     create table subcategory (  seo網站關鍵詞優化 id int not null primary key,  category int not null,  index(category)  ) engine=InnoDB;    create table item(  id int not null auto_increment primary key,  subcategory int not null,  index(subcategory)  ) engine=InnoDB;    我又往表里面填入一些樣本數據    [sql]  復制代碼 代碼如下:     insert into subcategory(id, category)  select i, i/100 from number  where i &l個業網站建設公司t;= 300000;    insert into item(subcategory)  select id  from (  select id, rand() * 20 as num_rows from subcategory  ) as x  cross join number  where i <= num_rows;    create temporary table t as  select subcategory from item  group by subcategory  having count(*) = 19  limit 100;    insert into item (subcategory)  select subcategory  from t  cross join number  where i < 2000;    再次說明，這些語句運行完需要一點時間，不適合放在產品環境中運行。思路是往item里插入隨機行數的數據，這樣subcategory就有1到2018之間個item。這不是實際中的完整數據，但效果一樣。   我想找出某個category中item數大于2000的全部subcategory。首先，我找到一個subcategory item數大于2000的，然后把它的category用在接下來的查詢中。這是具體的查詢語句：   [sql]  復制代碼 代碼如下:     select c.id  from subcategory as c  inner join item as i on i.subcategory = c.id  group by c.id  having count(*) > 2000;    -- choose one of the results, then  select * from subcategory where id = ????  -- result: category = 14    我拿到一個合適的值14，在以下的查詢中會用到它。這是用來查詢category 14 中所有item數大于2000的subcategory的語句：   [sql]  復制代碼 代碼如下:     select c.id  from subcategory as c  inner join item as i on i.subcategory = c.id  where c.category = 14  group by c.id  having count(*) > 2000;    在我的樣例數據里，查詢的結果有10行記錄，而且只用10多秒就完成了。EXPLAIN顯示出很好地使用了索引；從數據的規模來看，相當不錯了。查詢計劃是在索引上遍歷并計算出目標記錄。目前為止，非常好。   這回假設我要從subcategory取出全部的字段。我可以把上面的查詢當成嵌套，然后用JOIN，或者SELECT MAX之類(既然分組集對應的值都是唯一的)，但也寫成跟下面的一樣的，有木有？   [sql]  復制代碼 代碼如下:     select * from subcategory  where id in (  select c.id  from subcategory as c  inner join item as i on i.subcategory = c.id  where c.category = 14  group by c.id  having count(*) > 2000  );    跑完這條查詢估計要從破曉到夕陽沉入大地。我不知道它要跑多久，因為我沒打算讓它無休止地跑下去。你可能認為，單從語句上理解，它會:a)計算出里面的查詢，找出那10個值，b)繼續找出那10條記錄，并且在primary索引上去找會非常地快。錯，這是實際上的查詢計劃：   [sql]  復制代碼 代碼如下:     *************************** 1. row ***************************  id: 1  select_type: PRIMARY  table: subcategory  type: ALL  possible_keys: NULL  key: NULL  key_len: NULL  ref: NULL  rows: 300783  Extra: Using where  *************************** 2. row ***************************  id: 2  select_type: DEPENDENT SUBQUERY  table: c  type: ref  possible_keys: PRIMARY,category  key: category  key_len: 4  ref: const  rows: 100  Extra: Using where; Using index; Using temporary; Using filesort  *************************** 3. row ***************************  id: 2  select_type: DEPEND網站seo優化ENT SUBQUERY  table: i  type: ref  possible_keys: subcategory  key: subcategory  key_len: 4  ref: c.id  rows: 28  Extra: Using index    如何你不熟悉如何分析mysql的語句查詢計劃，請看大概意思：mysql計劃從外到內執行查詢，而不是從內到外。我會一個一個地介紹查詢的每個部分。   外面的查詢簡單地變成了SELECT * FROM subcategory。雖然里面的查詢對subcategory有個約束（WHERE category = 14），但出于某些原因mysql沒有將它作用于外面的查詢。我不知道是神馬原因。我只知道它掃描了整張表(這就是 type:ALL 表示的意思)，并且沒有使用任何的索引。這是在10幾萬行記錄的表上掃描。   在外面的查詢，對每行都執行一次里面的查詢，盡管沒有值被里面的查詢使用到，因為里面的查詢被“優化”成引用外面的查詢。照此分析，查詢計劃變成了嵌套循環。外面的查詢的每一次循環，都執行一次里面的查詢。下面就是優化器重寫后的查詢計劃：   [sql]  復制代碼 代碼如下:相關網站建設多少錢網站推廣優化seo。

關鍵詞標簽: 標簽 嵌套