在mysql中進行分頁查詢時，一般會使用limit查詢，而且通常查詢中都會使用orderby排 序。但是在表資料量比較大的時候，例如查詢語句片段limit 10000， 20，資料庫會讀取10020條資料，然後把前10000條丟棄，把最後的20條返回給你，這種消耗是可以避免的，也是沒必要的。下邊介紹幾種優化方法：
優化方法1（讓分頁操作在索引中進行）：
一般表中經常作為條件查詢的列都會建立索引，例如如下查詢
sql**
select msg_id, msg_content from message order by gmt_create desc limit 100, 20;
可以寫成如下方式
sql**
select msg_id, msg_content from message
inner join (
select msg_id from message
order by gmt_create limit 100, 20
) as page using(msg_id);
這樣當前查詢頁的內容就只會在索引中進行，當得到當前頁的msg_id再統一通過乙個inner join得到最終要得到的資料詳情，避免了對大量資料詳情進行操作的消耗。當然join操作也可以通過子查詢實現，不過書中介紹5.6之前版本的 mysql相比子查詢還是優先使用join。
優化方法2（顯式指定要查詢的索引列範圍）
例如方法一中的gmt_create是建立索引的列，而且你也知道要查詢的時間範圍，這樣你就可以通過如下查詢語句：
sql**
select msg_id, msg_content from message
where gmt_create between #starttime# and #endtime#
order by gmt_create desc
這樣資料庫通過乙個範圍查詢就可以得到想要的資料。
優化方法3（offset作為查詢條件顯式指定）
例子還是如上，我們可以在查詢引數中顯式指定乙個查詢時間，叫做lastvisittime吧。我們查詢第一頁可以用如下語句：
sql**
select msg_id, msg_content from message
order by gmt_create desc
limit 20
我們把讀出來的資料的最後一條資料的gmt_create欄位記錄在lastvisittime欄位中，那麼後邊頁的查詢就可以用如下語句實現：
sql**
select msg_id, msg_content from message
where gmt_create < #lastvisittime#
order by gmt_create desc
limit 20;
這種查詢方式，無論你查詢多少頁，分頁都不會是影響效率的因素。
mysql limit分頁查詢效率
對於有大資料量的mysql表來說，使用limit分頁存在很嚴重的效能問題。查詢從第1000000之後的30條記錄 sql 1 平均用時6.6秒 select from cdb posts order by pid limit 1000000 30 sql 2 平均用時0.6秒 select from...
mysql limit分頁查詢優化寫法
在mysql中進行分頁查詢時，一般會使用limit查詢，而且通常查詢中都會使用orderby排 序。但是在表資料量比較大的時候，例如查詢語句片段limit 10000，20，資料庫會讀取10020條資料，然後把前10000條丟棄，把最後的20條返回給你，這種消耗是可以避免的，也是沒必要的。下邊介紹幾...
Mysql Limit 分頁查詢優化詳解
select from table limit 5,10 返回第6 15行資料 select from table limit 5 返回前5行 select from table liwww.cppcns.commmfxqoydit 0,5 返回前5行 我們來寫分頁 物理分頁 semfxqoydle...