如  庫中有表  

當我們查詢使用語句
select * from teacher a WHERE a.id in (SELECT id  from student); 
用  EXPLAIN EXTENDED 可以粗略的檢視它的效能  
 查詢結果

這樣的話因為資料量少時間的差別幾乎很渺小


  內部 其實是 當我們在使用標量查詢in 的時候，其實mysql 內部轉換為了exists  下面的語句是等同的
EXPLAIN  EXTENDED select * from teacher a WHERE a.id in (SELECT id  from student);
EXPLAIN  EXTENDED select * from teacher a WHERE a.id EXISTS (SELECT id  from student);

。。

sql 內部的優化器預設的in 的使用載入時 LAZY 模式， 如果結果返回的是M列N

行，內部的掃描時間花費為其實為 Q（（M+1）×N） 毫秒

（select id from student ） 雖然是獨立的一個子查詢結構，但在in 的語句下又轉換為了相關子子查詢。。Mysql 官方手冊預設
 sql 的預設殷勤為Innodb但是在MariaDb 5.3版本的 殷勤中提供了對獨立子查詢的優化甚至我們可以繼續優化為
set  OPTIMIZE ='Materialization=ON'

  當然對於獨立空間表的優化，我們還可以用optimize
  innode 的殷勤優化 則先

  on 代表的獨立表空間開啟的

然後再

  這裡之所以報錯，因為mysql的 搜尋型別的問題，

  因為表的資料少，sql語句過於簡單，對於表的查詢型別用的simple

 其實我們作為程式設計師，寫的sql 語句幾乎一大半都欠缺優化，當然不是各種專案加班，BUG等等根本沒有多餘的時間考慮這些問題。。

 總結： 對於查詢的語句，大部分都關係到多表查詢，因此 我們 的原則 為： 能用派生表，絕對不用子查詢和關聯查詢

     我說的有可能比較模糊，直接上sql 吧

         查詢員工最大訂單日期的訂單 例：

   (1)

（2）

（3） 派生表B 查詢

   （1） sql 根本不對，因為如果根據訂單來，同一時間使用者很有可能購置多個訂單

（2） 結果正確，但效率很慢。

（3） 用派生表B，限制條件無非就一個日期，ID 嗎。引入這些條件其實跟2子查詢結是相同的，單效率就快的多

  原因呢：因為INNO 的殷勤 它執行邏輯 IO 的大大次數減少， （2）的 邏輯IO次數可能幾萬次，（3）的邏輯io次則為幾千次

       IO的邏輯次數（在記憶體中Mysql 建立虛擬表，還是進行一行的比較 都算作一次邏輯IO   ，建立虛擬表的時候有沒有進行物理IO ??[ 這個暫時不清楚嘿嘿 ]）

  IO （可以暫時理解為輸入輸出流）