mysql使⽤⼦查询优化分页_使⽤⼦查询提⾼MySQL分页效率
limit
1.LIMITn等价于LIMIT0,n偏移offt较⼩的时候，直接使⽤limit较优。 2、offt⼤的时候。 lect * from yanxue8_visit limit 10000,10 多次运⾏，时间保持在0.0187左右 Select * From yanxue8_visit Where vid =( Select vid From yanxue8_visit Order By v
1.LIMIT n 等价于 LIMIT 0,n 偏移offt较⼩的时候，直接使⽤limit较优。
2、offt⼤的时候。
lect * from yanxue8_visit limit 10000,10
多次运⾏，时间保持在0.0187左右
Select * From yanxue8_visit Where vid >=(
Select vid From yanxue8_visit Order By vid limit 10000,1
) limit 10
多次运⾏，时间保持在0.0061左右，只有前者的1/3。可以预计offt越⼤，后者越优
性能优化：基于MySQL5.0中limit的⾼性能，我对数据分页也重新有了新的认识.
1.
Select * From cyclopedia Where ID>=(Select Max(ID) From (Select ID From cyclopedia Order By ID limit90001) As tmp) limit 100;
2.
Select * From cyclopedia Where ID>=(Select Max(ID) From ( Select ID From cyclopedia Order By ID limit90000,1) As tmp) limit 100;
同样是取90000条后100条记录，第1句快还是第2句快?
第1句是先取了前90001条记录，取其最⼤ID值作为起始，然后快速定位下100条记录
第2句择是仅仅取90000条记录后1条，然后取ID值作起始标识定位下100条记录
健身心得
关于飞机的电影很明显第2句胜出.看来limit好像并不完全像我之前想象的那样做全表扫描返回limit offt+length条记录，
心灵驿站这样看来limit⽐起MS-SQL的Top性能还是要提⾼不少的.
可是，既然MySQL有limit可以直接控制取出记录的位置，为什么不⼲脆⽤Select * From cyclopedia limit90000,1呢? 岂不更简洁?
年末收官这样想就错了，试了就知道，结果是:1 row in t (8.88)c，怎么样，够吓⼈的吧，让我想起了昨天在4.1中⽐这还有过之的"⾼分" .Select *最好不要随便⽤，要本着⽤什么，选什么的原则, Select的字段越多，字段数据量越⼤，速度就越慢.上⾯2种分页⽅式哪种都⽐单写这1句强多了，虽然看起来好像查询的次数更多⼀些，但实际上是以较⼩的代价换取了⾼效的性能，是⾮常值得的.
烤番薯靠主键ID来定位起始段总是最快
但不管是实现⽅式是存贮过程还是直接代码中，瓶颈始终在于MS-SQL的TOP总是要返回前N个记录，这种情况在数据量不⼤时感受不深，但如果成百上千万，效率肯定会低下的.相⽐之下MySQL的limit就有优势的多，执⾏:
LIMIT 思考
手机内存多大合适PERCONA PERFORMANCE CONFERENCE 2009上，来⾃雅虎的⼏位⼯程师带来了⼀篇”EfficientPagination Using MySQL“的报告，有很多亮点，本⽂是在原⽂基础上的进⼀步延伸。⾸先
看⼀下分页的基本原理：
limit10000,20的意思扫描满⾜条件的10020⾏，扔掉前⾯的10000⾏，返回最后的20⾏，问题就在这⾥，如果是limit100000,100，需要扫描100100⾏，在⼀个⾼并发的应⽤⾥，每次查询需要扫描超过10W⾏，性能肯定⼤打折扣。⽂中还提到limit n性能是没问题的，因为只扫描n⾏。
⽂中提到⼀种”clue”的做法，给翻页提供⼀些”线索”，⽐如还是SELECT * FROM message ORDER BYidDESC，按id降序分页，每页20条，当前是第10页，当前页条⽬id最⼤的是9527，最⼩的是9500
SELECT * FROM message WHERE id > 9527 ORDER BYid ASC LIMIT 20;
SELECT * FROM message WHERE id < 9500 ORDER BYid DESC LIMIT 20;
不管翻多少页，每次查询只扫描20⾏。朋友这杯酒
如果LIMIT m,n不可避免的话，要优化效率，只有尽可能的让m⼩⼀下，我们扩展前⾯的”clue”做法，还是SELECT *FROM message ORDER BY idDESC，按id降序分页，每页20条，当前是第10页，当前页条⽬id最⼤的是9527，最⼩的是9500，⽐如要跳到第8页，我看的SQL语句可以这样写：
SELECT * FROM message WHERE id > 9527 ORDER BYid ASC LIMIT 20,20;
跳转到第13页：
SELECT * FROM message WHERE id < 9500 ORDER BYid DESC LIMIT 40,20;
原理还是⼀样，记录住当前页id的最⼤值和最⼩值，计算跳转页⾯和当前页相对偏移，由于页⾯相近，这个偏移量不会很⼤，这样的话m值相对较⼩，⼤⼤减少扫描的⾏数。其实传统的limitm,n，相对的偏移⼀直是第⼀页，这样的话越翻到后⾯，效率越差，⽽上⾯给出的⽅法就没有这样的问题。
注意SQL语句⾥⾯的ASC和DESC，如果是ASC取出来的结果，显⽰的时候记得倒置⼀下。已在60W数据总量的表中测试，效果⾮常明显。
分享
本⽂原创发布php中⽂⽹，转载请注明出处，感谢您的尊重！
