狠狠撸

狠狠撸Share a Scribd company logo
高效的 MySQL 分页

April 29th, 2009 | by 超群.com | 知识共享署名-非商业性使用-相同方式共享,转载请保留
链接。

PERCONA PERFORMANCE CONFERENCE 2009 上,来自雅虎的几位工程师带来了一
篇”Efficient Pagination Using MySQL“的报告,有很多亮点,本文是在原文基础上的进一步
延伸。


 首先看一下分页的基本原理:


mysql> explain SELECT * FROM message ORDER BY id DESC LIMIT 10000, 20G
** 1. row ****
id: 1
select_type: SIMPLE
table: message
type: index
possible_keys: NULL
key: PRIMARY
key_len: 4
ref: NULL
rows: 10020
Extra:
1 row in set (0.00 sec)

limit 10000,20 的意思扫描满足条件的 10020 行,扔掉前面的 10000 行,返回最后的 20
行,问题就在这里,如果是 limit 100000,100,需要扫描 100100 行,在一个高并发的应用
里,每次查询需要扫描超过 10W 行,性能肯定大打折扣。文中还提到 limit n 性能是没问题
的,因为只扫描 n 行。


 文中提到一种”clue”的做法,给翻页提供一些”线索”,比如还是 SELECT * FROM
 message ORDER BY id DESC,按 id 降序分页,每页 20 条,当前是第 10 页,当前页条
 目 id 最大的是 9527,最小的是 9500,如果我们只提供”上一页”、”下一页”这样的跳转
 (不提供到第 N 页的跳转),那么在处理”上一页”的时候 SQL 语句可以是:


SELECT * FROM message WHERE id > 9527 ORDER BY idASC LIMIT 20;


 处理”下一页”的时候 SQL 语句可以是:


SELECT * FROM message WHERE id < 9500 ORDER BY idDESC LIMIT 20;

不管翻多少页,每次查询只扫描 20 行。
缺点是只能提供”上一页”、”下一页”的链接形式,但是我们的产物经理非常喜欢”<上一页 1 2
3 4 5 6 7 8 9 下一页>”这样的链接方式,怎么办呢?


 如果 LIMIT m,n 不可避免的话,要优化效率,只有尽可能的让 m 小一下,我们扩展前面
 的”clue”做法,还是 SELECT * FROM message ORDER BY id DESC,按 id 降序分页,
 每页 20 条,当前是第 10 页,当前页条目 id 最大的是 9527,最小的是 9500,比如要跳到
 第 8 页,我看的 SQL 语句可以这样写:


SELECT * FROM message WHERE id > 9527 ORDER BY idASC LIMIT 20,20;


 跳转到第 13 页:


SELECT * FROM message WHERE id < 9500 ORDER BY idDESC LIMIT 40,20;

原理还是一样,记录住当前页 id 的最大值和最小值,计算跳转页面和当前页相对偏移,由于页
面相近,这个偏移量不会很大,这样的话 m 值相对较小,大大减少扫描的行数。其实传统的
limit m,n,相对的偏移一直是第一页,这样的话越翻到后面,效率越差,而上面给出的方法就
没有这样的问题。

注意 SQL 语句里面的 ASC 和 DESC,如果是 ASC 取出来的结果,显示的时候记得倒置一下。

已在 60W 数据总量的表中测试,效果非常明显。

Tags: MySQL, Performance

More Related Content

高效的惭测厂蚕尝分页

  • 1. 高效的 MySQL 分页 April 29th, 2009 | by 超群.com | 知识共享署名-非商业性使用-相同方式共享,转载请保留 链接。 PERCONA PERFORMANCE CONFERENCE 2009 上,来自雅虎的几位工程师带来了一 篇”Efficient Pagination Using MySQL“的报告,有很多亮点,本文是在原文基础上的进一步 延伸。 首先看一下分页的基本原理: mysql> explain SELECT * FROM message ORDER BY id DESC LIMIT 10000, 20G ** 1. row **** id: 1 select_type: SIMPLE table: message type: index possible_keys: NULL key: PRIMARY key_len: 4 ref: NULL rows: 10020 Extra: 1 row in set (0.00 sec) limit 10000,20 的意思扫描满足条件的 10020 行,扔掉前面的 10000 行,返回最后的 20 行,问题就在这里,如果是 limit 100000,100,需要扫描 100100 行,在一个高并发的应用 里,每次查询需要扫描超过 10W 行,性能肯定大打折扣。文中还提到 limit n 性能是没问题 的,因为只扫描 n 行。 文中提到一种”clue”的做法,给翻页提供一些”线索”,比如还是 SELECT * FROM message ORDER BY id DESC,按 id 降序分页,每页 20 条,当前是第 10 页,当前页条 目 id 最大的是 9527,最小的是 9500,如果我们只提供”上一页”、”下一页”这样的跳转 (不提供到第 N 页的跳转),那么在处理”上一页”的时候 SQL 语句可以是: SELECT * FROM message WHERE id > 9527 ORDER BY idASC LIMIT 20; 处理”下一页”的时候 SQL 语句可以是: SELECT * FROM message WHERE id < 9500 ORDER BY idDESC LIMIT 20; 不管翻多少页,每次查询只扫描 20 行。
  • 2. 缺点是只能提供”上一页”、”下一页”的链接形式,但是我们的产物经理非常喜欢”<上一页 1 2 3 4 5 6 7 8 9 下一页>”这样的链接方式,怎么办呢? 如果 LIMIT m,n 不可避免的话,要优化效率,只有尽可能的让 m 小一下,我们扩展前面 的”clue”做法,还是 SELECT * FROM message ORDER BY id DESC,按 id 降序分页, 每页 20 条,当前是第 10 页,当前页条目 id 最大的是 9527,最小的是 9500,比如要跳到 第 8 页,我看的 SQL 语句可以这样写: SELECT * FROM message WHERE id > 9527 ORDER BY idASC LIMIT 20,20; 跳转到第 13 页: SELECT * FROM message WHERE id < 9500 ORDER BY idDESC LIMIT 40,20; 原理还是一样,记录住当前页 id 的最大值和最小值,计算跳转页面和当前页相对偏移,由于页 面相近,这个偏移量不会很大,这样的话 m 值相对较小,大大减少扫描的行数。其实传统的 limit m,n,相对的偏移一直是第一页,这样的话越翻到后面,效率越差,而上面给出的方法就 没有这样的问题。 注意 SQL 语句里面的 ASC 和 DESC,如果是 ASC 取出来的结果,显示的时候记得倒置一下。 已在 60W 数据总量的表中测试,效果非常明显。 Tags: MySQL, Performance