概述

有朋友問(wèn): MySQL的分頁(yè)似乎一直是個(gè)問(wèn)題，有什么優(yōu)化方法嗎？
網(wǎng)上看到趕集網(wǎng)XX推薦了一些分頁(yè)方法,但似乎不太可行，你能點(diǎn)評(píng)一下嗎？

方法總結(jié)

方法1: 直接使用數(shù)據(jù)庫(kù)提供的SQL語(yǔ)句

語(yǔ)句樣式: MySQL中,可用如下方法: SELECT * FROM 表名稱 LIMIT M,N
適應(yīng)場(chǎng)景: 適用于數(shù)據(jù)量較少的情況(元組百/千級(jí))
原因/缺點(diǎn): 全表掃描,速度會(huì)很慢 且 有的數(shù)據(jù)庫(kù)結(jié)果集返回不穩(wěn)定(如某次返回1,2,3,另外的一次返回2,1,3). Limit限制的是從結(jié)果集的M位置處取出N條輸出,其余拋棄.

方法2: 建立主鍵或唯一索引, 利用索引(假設(shè)每頁(yè)10條)

語(yǔ)句樣式: MySQL中,可用如下方法: SELECT FROM 表名稱 WHERE id_pk > (pageNum10) LIMIT M
適應(yīng)場(chǎng)景: 適用于數(shù)據(jù)量多的情況(元組數(shù)上萬(wàn))
原因: 索引掃描,速度會(huì)很快. 有朋友提出: 因?yàn)閿?shù)據(jù)查詢出來(lái)并不是按照pk_id排序的，所以會(huì)有漏掉數(shù)據(jù)的情況，只能方法3

方法3: 基于索引再排序

語(yǔ)句樣式: MySQL中,可用如下方法: SELECT FROM 表名稱 WHERE id_pk > (pageNum10) ORDER BY id_pk ASC LIMIT M
適應(yīng)場(chǎng)景: 適用于數(shù)據(jù)量多的情況(元組數(shù)上萬(wàn)). 最好ORDER BY后的列對(duì)象是主鍵或唯一所以,使得ORDERBY操作能利用索引被消除但結(jié)果集是穩(wěn)定的(穩(wěn)定的含義,參見(jiàn)方法1)
原因: 索引掃描,速度會(huì)很快. 但MySQL的排序操作,只有ASC沒(méi)有DESC(DESC是假的,未來(lái)會(huì)做真正的DESC,期待…).

方法4: 基于索引使用prepare（第一個(gè)問(wèn)號(hào)表示pageNum，第二個(gè)？表示每頁(yè)元組數(shù)）
語(yǔ)句樣式: MySQL中,可用如下方法: PREPARE stmt_name FROM SELECT FROM 表名稱 WHERE id_pk > (？ ？) ORDER BY id_pk ASC LIMIT M
適應(yīng)場(chǎng)景: 大數(shù)據(jù)量
原因: 索引掃描,速度會(huì)很快. prepare語(yǔ)句又比一般的查詢語(yǔ)句快一點(diǎn)。

方法5: 存儲(chǔ)過(guò)程類(lèi)（最好融合上述方法4)

語(yǔ)句樣式: 不再給出
適應(yīng)場(chǎng)景: 大數(shù)據(jù)量. 作者推薦的方法
原因: 把操作封裝在服務(wù)器，相對(duì)更快一些。

方法6: 反面方法

網(wǎng)上有人寫(xiě)使用 SQL_CALC_FOUND_ROWS。 沒(méi)有道理，勿模仿