mysql大数据量分页查询优化策略(原创)

第一此慢 不好解决，不过 把
have_query_cache 设置为 YES
用 SHOW VARIABLES LIKE ‘have_query_cache’ 看
用SHOW STATUS LIKE ‘Qcache%’  看缓存状态变量

看看手册，书 改改你的  VARIABLES 估计能提高一些性能

http://bbs.phpchina.com/viewthread.php?tid=22293

 

优化limit和offset
MySQL的limit工作原理就是先读取n条记录，然后抛弃前n条，读m条想要的，所以n越大，性能会越差。
优化前SQL: SELECT * FROM member ORDER BY last_active LIMIT 50,5
优化后SQL: SELECT * FROM member INNER JOIN (SELECT member_id FROM member ORDER BY last_active LIMIT 50, 5) USING (member_id)
分别在于，优化前的SQL需要更多I/O浪费，因为先读索引，再读数据，然后抛弃无需的行。而优化后的SQL(子查询那条)只读索引(Cover index)就可以了，然后通过member_id读取需要的列。

其实你可以去查看一下一些大型的交友网站,你会发现他们的搜索结果始终是一固定的页数(当然这也是建立在大数据量的情况下),它会把当前你搜索的所有结果 保存到某一位置,如数据库,MEMCACHE………,然后利用这些数据再进行分页,这样分页的记录相对来说就会少很多
其实对于大数据量的分页,你给他一个几十页的数据浏览,已经够了,没必要每次分页都去源数据库,不停的找,前几页还好,愈往后查询效率肯定也会慢慢变差,所以来说,建立一个空间保存搜索结果比较合适,不过还是看你是否真的有大数据量
如果只是上百万数据量的分页,也没太必要使用上面的方式,你只要在某个时间段内保存搜索的总记录数,这样避免了每次去搜索时还得去搜索总记录数的二次开销,再建立正确的索引,搜索速度还是可以接受的

http://topic.csdn.net/u/20100719/16/a7079a9f-ffa8-489c-a655-11b832bf6126.html

 

解决方案：

一：对用户读取的页数做限制，一个正常的用户是不需要读取到几十万页之后的数据，所以可以对用户的读取也数做限制，这个是不会影响到用户体验的，但是这部分数据就无法读取了

 

二：对数据进行倒序排列，由于我的id字段是自增长的我可以对他进行倒序排列，然后读取前几条数据，当然这种数据的读取是需要算法支持的，倒序的排列读取涉及到的是偏移量的设置，这种读取的速度用户是可以接受的返回熟读在2S以内！

http://www.cnblogs.com/gaocheng/archive/2010/08/02/1790651.html

 

有些程序员很懒，或者没有考虑过这个问题，经常会在取结果的时候一直按照同一种排序方式，而没有考虑到当该排序方式碰到超大结果集时会变得非常慢的问题。 因此，我们可以在程序中约定，当按原来的排序方式取得结果过程中，如果LIMIT START,OFFSET中的START的值超过总记录数的一定比例(例如一半)，就将排序方式倒过来，虽然这么做可能会导致一些其他小问题，但我认为这 是非常值得的。

http://imysql.cn/2007_08_19_mysql_sort_order