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

 

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

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

 

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

MySQL分頁優(yōu)化中，有一種經(jīng)典的問題，在查詢?cè)健翱亢蟆钡臄?shù)據(jù)越慢（取決于表上的索引類型，對(duì)于B樹結(jié)構(gòu)的索引，SQL Server中也一樣）
select * from t order by id limit m,n。
也即隨著M的增大，查詢同樣多的數(shù)據(jù)，會(huì)越來越慢
面對(duì)這一問題，于是就產(chǎn)生了一種經(jīng)典的做法，類似于（或者變種）如下的寫法
就是先把分頁范圍內(nèi)的id單獨(dú)找出來，然后再跟基表做關(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

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