最近，幫同事重寫了一個MySQL SQL語句，該SQL語句涉及兩張表，其中一張表是字典表（需返回一個字段），另一張表是業務表（本身就有150個字段，需全部返回），當然，字段的個數是否合理在這里不予評價。平時，返回的數據大概5w左右，系統尚能收到數據。但12月31日那天，數據量大概20w，導致SQL執行時間過長，未能在規定的時間內反饋結果，于是系統直接報錯。

一般的思路是用MySQL的分頁功能，即直接在原SQL語句后面增加LIMIT子句。但請注意，雖然你看到的反饋結果只是LIMIT后面指定的數量，于是想當然的以為MySQL只是檢索了指定數量的數據，然后給予返回。其實，MySQL內部實現的原理是，檢索所有符合where條件的記錄，然后返回指定數量的記錄。從這個角度來看，直接在原SQL語句后面添加LIMIT子句只能說是一種可以實現功能的方案，但未必最優。

具體在本例中，首先我們來看一下150個字段的表的統計信息：

一行大概就占2k，而Innodb默認頁的大小為16k，這意味著，一個頁中最多可存儲8行的數據。隨機讀的可能性大大增加。而這無疑會對數據庫系統的IO造成極大的壓力。 

優化前

如果采用上述方案，即直接在原SQL語句后面增加LIMIT子句，下面，我們來看看它的執行情況。

首先，直接添加LIMIT子句后的SQL語句如下（已省略a1表的150個字段和a2中的一個字段）：

大概執行了32s，絕大部分都花費到Sending data上了。Sending data指的是服務器檢索數據，讀取數據，并將數據返回給客戶端的時間。

關于上述執行結果，有以下幾點需要說明：

1. 這是SQL語句多次執行后的結果，這樣就可以排除結果緩存的影響，事實上，每次查詢的時長都是32s左右。

2. 為什么選用的是limit 50000,10000，而不是0，10000，這個主要是考慮到對于LIMIT子句來說，越到后面，分頁的成本越高。基于此，選擇了中間值來作為分頁的結果。

該語句的執行計劃如下：

優化后：

優化的思路：

只對該表的主鍵進行分頁，然后用返回的主鍵作為子查詢的結果，來檢索該表其它字段的值。