本文出處：http://www.cnblogs.com/wy123/p/7003157.html 

 

最近無意間看到一個MySQL分頁優(yōu)化的測試案例，并沒有非常具體地說明測試場景的情況下，給出了一種經(jīng)典的方案，
因為現(xiàn)實中很多情況都不是固定不變的，能總結(jié)出來通用性的做法或者說是規(guī)律，是要考慮非常多的場景的，
同時，面對能夠達到優(yōu)化的方式要追究其原因，同樣的做法，換了個場景，達不到優(yōu)化效果的，還要追究其原因。
個人對此場景在不用情況表示懷疑，然后自己測試了一把，果然發(fā)現(xiàn)一些問題，同時也證實了一些預(yù)期的想法。
本文就MySQL分頁優(yōu)化，從最最簡單的情況出發(fā)，來做一個簡單的分析。

另：本文測試環(huán)境是最最低配置的云服務(wù)器，相對來說服務(wù)器硬件環(huán)境有限，不過對于不同的語句（寫法）應(yīng)該是“平等的”

 

MySQL經(jīng)典的分頁“優(yōu)化”做法

MySQL分頁優(yōu)化中，有一種經(jīng)典的問題，在查詢越“靠后”的數(shù)據(jù)越慢（取決于表上的索引類型，對于B樹結(jié)構(gòu)的索引，SQL Server中也一樣）
select * from t order by id limit m,n。
也即隨著M的增大，查詢同樣多的數(shù)據(jù)，會越來越慢
面對這一問題，于是就產(chǎn)生了一種經(jīng)典的做法，類似于（或者變種）如下的寫法
就是先把分頁范圍內(nèi)的id單獨找出來，然后再跟基表做關(guān)聯(lián)，最后查詢出來所需要的數(shù)據(jù)
select * from t
inner join (select id from t order by id limit m,n)t1 on t1.id = t.id

這種做法是不是總是生效的，或者