Innodb表select查詢順序

今天知數(shù)堂一個學(xué)生反饋說在優(yōu)化課中老師講Innodb是以主鍵排序存儲，讀取的時間以主鍵為順序讀取，但發(fā)現(xiàn)個例外，如下：

CREATE TABLE zst_t1 ( 

uid int(10) NOT NULL AUTO_INCREMENT, 

id int(11) NOT NULL, 

PRIMARY KEY ( uid ), 

KEY idx_id ( id ) 

) ENGINE=InnoDB；'

寫入數(shù)據(jù)：

INSERT INTO zst_t1 VALUES (1,1),(12,1),(22,1),(23,1),(33,1),(2,2),(3,2),(10,2),(11,2),(4,4),(13,4),(14,4); 

執(zhí)行查詢：

select * from zst_t1;

為什么這個順序是亂的，不按順序排列呢？難道Innodb表并不是全按主鍵存儲？

使用innodb_ruby這個工具查看一下存儲結(jié)構(gòu)什么樣

看樣子存儲還是按主鍵排序存儲的。沒毛病。

再來看一下該表的索引：

看到這里應(yīng)該明白了怎么會事了吧，原來這個查詢是走的索引覆蓋，沒有在進行回表讀取原數(shù)據(jù)。另外，也在此說明，Innodb二索索引包含了主鍵存儲。

來繼續(xù)證明一下：

看到using index 吧，表示這個查詢利用索引查詢出來結(jié)果，不用讀取原表。

那么我們給造一個通過主鍵讀取數(shù)據(jù)操作：

select * from zst_t1 use index(primary);

select * from zst_t1 use index(primary);  #確認(rèn)一下。

總結(jié)：

這個其實就是一個索引包含的查詢案例。 如果靜下來思考一下，也許很快就明白了。也不用這樣去查問題。

技術(shù)在于折騰，多搞搞就明白了：）。