記面試中問到的MySQL的SQL調優問題

面試官：小夥子，聽說你會sql調優，那我這裡有一條sql，你來幫我調優一下。sql如下:select * from t limit 899999, 10;表結構如下:

id int(10) primary key,
其他字段……

我：¿¿¿（緩緩打出反問號），這條sql要幹嘛，隨機找10條資料嗎？

面試官：哦，不好意思，忘記加上排序了select * from t order by id limit 899999, 10;

我：如果id是連續不中斷的話可以這樣寫。 sql如下：select * from t where id >= 899999 limit 0, 10;

面試官：那假如id不是連續的呢？

我：（略加思考）單從sql優化層面我優化不了了。

我：……

面試官：那最後你有什麼問題想問我的嗎？

我：剛才那條sql從sql層面上該如何優化？

面試官：你可以這樣寫：select * from t t where t.id >= (select f.id from t f order by id desc limit 899999, 1) limit 0, 10;

我：（假裝略加思考）你確定這樣寫會比圖一這條sql：select * from t order by id limit 899999, 10;更快嗎？在圖一的sql裡已經是通過主鍵索引去查詢資料了，你圖二的sql並沒有改變原有的查詢方式。如果你原有sql是通過其他欄位去排序的，用的是非主鍵索引，例如：select * from t order by createdtime limit 899999, 10;那麼你第二條sql的寫法確實會比第一條sql快得多，因為在mysql裡非主鍵索引與主鍵索引在查詢上的區別是，非主鍵索引他儲存的是索引列與主鍵列的值，查詢具體的值還需要一次回表過程，而主鍵索引儲存了是整行資料，不需要再次***回表***[^①]查詢，減少了一次查詢過程。

面試官：……

我：……

指查詢時通過非主鍵索引（非聚簇索引）去查詢對應的記錄的主鍵後，仍需要根據主鍵進行再一次的查詢，這是mysql的索引結構引起的。在mysql中，主鍵索引（聚簇索引）儲存的是一整行的資料，而非主鍵索引（非聚簇索引）儲存的是主鍵列的值。

假如有這樣一張表

create table person (
id int(11) not null,
name varchar(32) not null,
age int(11) not null,
primary key (id),
key idx_person_age (age)
) engine=innodb default charset=utf8mb4;

那這張表的索引具體表現形式如下：

主鍵索引：

非主鍵索引：

所以當我們需要查詢age=30的資料時，他的查詢過程如下圖：

如今我有這樣一張表：

create table file (
id int(11) not null auto_increment,
name varchar(255) default null,
created_time datetime not null,
updated_time datetime not null,
primary key (id),
key idx_file_created_time (created_time) using btree
) engine=innodb auto_increment=954185 default charset=utf8mb4;

表的資料數量為：

先來看看面試官說的情況

可以看出，查詢時間並沒有很大的差距，這是因為這兩條sql都是走的主鍵索引，方式並沒有很大的差別

而我列舉的情況，通過時間字段進行排序，讓其產生回表操作的過程。

可以看出，查詢時間出現了很大的差距，這是由於回表操作所造成的。

這個場景就發生在我上星期的面試中，我不知道這個面試官出這個題時是故意留坑還是什麼情況，但是在後面他給出他那答案時，實在是讓我驚訝，希望他是一時的錯誤，若是他對sql的本身理解就不熟悉，那就……………………

（1）在file表中，假如我所查詢的資料列只有id、created_time與updated_time，那麼還可以怎麼做？

（2）當真的只能通過id進行排序分頁時，我們該怎麼做？

記面試中問到的MySQL的SQL調優問題

面試中經常問到的問題

面試中被問到的概率題

每次面試都被問到的linux

記面試中問到的MySQL的SQL調優問題

面試中經常問到的問題

面試中被問到的概率題

每次面試都被問到的linux

相關推薦