今天知數(shù)堂一個學生反饋說在優(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;
![](/d/20211018/ef0b14fd51c56f87bf1c16f95bcefb81.gif)
為什么這個順序是亂的,不按順序排列呢?難道Innodb表并不是全按主鍵存儲?
使用innodb_ruby這個工具查看一下存儲結構什么樣
![](/d/20211018/643ea189f12cc051192b6bd5d55bad69.gif)
看樣子存儲還是按主鍵排序存儲的。沒毛病。
再來看一下該表的索引:
![](/d/20211018/b5db12d695cf5d974bf25eb1b3b78984.gif)
看到這里應該明白了怎么會事了吧,原來這個查詢是走的索引覆蓋,沒有在進行回表讀取原數(shù)據(jù)。另外,也在此說明,Innodb二索索引包含了主鍵存儲。
來繼續(xù)證明一下:
![](/d/20211018/1c9ffcf8c217f9b43944034393b6f3ea.gif)
看到using index 吧,表示這個查詢利用索引查詢出來結果,不用讀取原表。
那么我們給造一個通過主鍵讀取數(shù)據(jù)操作:
select * from zst_t1 use index(primary);
![](/d/20211018/c5b1badf423dc0ab2a060fb7bbca08c6.gif)
select * from zst_t1 use index(primary);
#確認一下。
![](/d/20211018/3b714379f3bbbb3163dfdc3d6e2c45d8.gif)
總結:
這個其實就是一個索引包含的查詢案例。 如果靜下來思考一下,也許很快就明白了。也不用這樣去查問題。
技術在于折騰,多搞搞就明白了:)。
您可能感興趣的文章:- 可以改善mysql性能的InnoDB配置參數(shù)
- MySQL Innodb表導致死鎖日志情況分析與歸納
- mysql更改引擎(InnoDB,MyISAM)的方法
- MySQL不支持InnoDB的解決方法
- Mysql啟動中 InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes 的問題
- 淺談MySQL存儲引擎選擇 InnoDB與MyISAM的優(yōu)缺點分析
- Xtrabackup使用指南 InnoDB數(shù)據(jù)備份工具
- MYSQL無法啟動提示: Default storage engine (InnoDB) is not available的解決方法
- MySQL數(shù)據(jù)庫INNODB表損壞修復處理過程分享