一、問題的引出
當mysql表中有資料量很大的時候如何做分頁?
很多應用往往只展示最新或最熱門的幾條記錄,但為了舊記錄仍然可訪問,所以就需要個分頁的導航欄。然而,如何通過mysql更好的實現分頁,始終是比較令人頭疼的問題。雖然沒有拿來就能用的解決辦法,但了解資料庫的底層或多或少有助於優化分頁查詢。
我們先從乙個常用但效能很差的查詢來看一看。
select *
from city
order by id desc
limit 0, 15
這個查詢耗時0.00sec。so,這個查詢有什麼問題呢?實際上,這個查詢語句和引數都沒有問題,因為它用到了下面表的主鍵,而且只讀取15條記錄。
create table city (
id int(10) unsigned not null auto_increment,
city varchar(128) not null,
primary key (id)
) engine=innodb;
真正的問題在於offset(分頁偏移量)很大的時候,像下面這樣:
select *
from city
order by id desc
limit 100000, 15;
上面的查詢在有2m行記錄時需要0.22sec,通過explain檢視sql的執行計畫可以發現該sql檢索了100015行,但最後只需要15行。大的分頁偏移量會增加使用的資料,mysql會將大量最終不會使用的資料載入到記憶體中。就算我們假設大部分**的使用者只訪問前幾頁資料,但少量的大的分頁偏移量的請求也會對整個系統造成危害。facebook就意識到了這一點,但facebook並沒有為了每秒可以處理更多的請求而去優化資料庫,而是將重心放在將請求響應時間的方差變小。
對於分頁請求,還有乙個資訊也很重要,就是總共的記錄數。我們可以通過下面的查詢很容易的獲取總的記錄數。
select count(*)
from city;
然而,上面的sql在採用innodb為儲存引擎時需要耗費9.28sec。乙個不正確的優化是採用sql_calc_found_rows,sql_calc_found_rows可以在能夠在分頁查詢時事先準備好符合條件的記錄數,隨後只要執行一句select found_rows(); 就能獲得總記錄數。但是在大多數情況下,查詢語句簡短並不意味著效能的提高。不幸的是,這種分頁查詢方式在許多主流框架中都有用到,下面看看這個語句的查詢效能。
select sql_calc_found_rows *
from city
order by id desc
limit 100000, 15;
這個語句耗時20.02sec,是上乙個的兩倍。事實證明使用sql_calc_found_rows做分頁是很糟糕的想法。
二、解決方法
下面來看看到底如何優化。分為兩部分,第一部分是如何獲取記錄的總數目,第二部分是獲取真正的記錄。
1、高效的計算行數
如果採用的引擎是myisam,可以直接執行count(*)去獲取行數即可。相似的,在堆表中也會將行數儲存到表的元資訊中。但如果引擎是innodb情況就會複雜一些,因為innodb不儲存表的具體行數。
我們可以將行數快取起來,然後可以通過乙個守護程序定期更新或者使用者的某些操作導致快取失效時,執行下面的語句:
select count(*)
from city
use index(primary);
獲取記錄。
2、獲取分頁要展示的記錄
面已經說過了,大的偏移量會影響效能,所以我們要重寫查詢語句。為了演示,我們建立乙個新的表「news」,按照時事性排序(最新發布的在最前面),實現乙個高效能的分頁。為了簡單,我們就假設最新發布的新聞的id也是最大的。
create table news(
id int unsigned primary key auto_increment,
title varchar(128) not null
) engine=innodb;
select *
from news where id < $last_id
order by id desc
limit $perpage
select *
from news where id > $last_id
order by id asc
limit $perpage
select id
from (
select id, ((@cnt:= @cnt + 1) + $perpage - 1) % $perpage cnt
from news
join (select @cnt:= 0)t
where id < $last_id
order by id desc
limit $perpage * $buttons
)cwhere cnt = 0;
通過上面的語句可以為每乙個分頁的按鈕計算出乙個offset對應的id。這種方法還有乙個好處。假設,**上正在發布一片新的文章,那麼所有文章的位置都會往後移一位,所以如果使用者在發布文章時換頁,那麼他會看見一篇文章兩次。如果固定了每個按鈕的offset id,這個問題就迎刃而解了。
如果表中的記錄很少被刪除、修改,還可以將記錄對應的頁碼儲存到表中,並在該列上建立合適的索引。採用這種方式,當新增乙個記錄的時候,需要執行下面的查詢重新生成對應的頁號。
set p:= 0;
update news set page=ceil((p:= p + 1) / $perpage) order by id desc;
當然,也可以新增乙個專用於分頁的表,可以用個後台程式來維護。
update pagination t
join (
select id, ceil((p:= p + 1) / $perpage) page
from news
order by id
)con c.id = t.id
set t.page = c.page;
現在想獲取任意一頁的元素就很簡單了:
select *
from news a
join pagination b on a.id=b.id
where page=$offset;
3、還有另外一種與上種方法比較相似的方法來做分頁,這種方式比較試用於資料集相對小,並且沒有可用的索引的情況下—比如處理搜尋結果時。在乙個普通的伺服器上執行下面的查詢,當有2m條記錄時,要耗費2sec左右。這種方式比較簡單,建立乙個用來儲存所有id的臨時表即可(這也是最耗費效能的地方)。
create temporary table _tmp (key sort(random))
select id, floor(rand() * 0x8000000) random
from city;
alter table _tmp add offset int unsigned primary key auto_increment, drop index sort, order by random;
接下來就可以向下面一樣執行分頁查詢了。
select *
from _tmp
where offset >= $offset
order by offset
limit $perpage;
總結:簡單來說,對於分頁的優化就是避免資料量大時掃瞄過多的記錄。
mysql的分頁優化 mysql分頁優化
有個200多萬的使用者表,顯示列表時非常慢,查了一下原來使用了limit進行分頁。前幾頁用時很少 但是後面頁數就簡直不可忍了,實際的業務邏輯還有排序,就更慢了 試試用查詢時用帶索引的鍵來確定範圍。最大的id是103948598 時間和用limit比相差幾千倍啊!使用explain 檢視一下 mysq...
mysql 分頁優化 Mysql 查詢分頁優化
全表掃瞄,速度極慢 limit 語句的查詢時間與起始記錄的位置成正比 mysql 的 limit 語句是很方便,但是對記錄很多的表並不適合直接使用 建立測試表 drop table if exists t user create table test t user id int 10 unsigne...
mysql 分頁優化 MySQL分頁優化實驗與總結
前言 分頁的sql優化是日常開發中經常遇到的問題,筆者在此做乙個經驗總結,並附上相應的實驗過程。實驗準備 若不想親自實驗的,可以直接跳過這一節。但還是建議大家做一下實驗,眼見為實。1.安裝測試資料庫 本次實驗使用的資料是mysql官方提供的employee資料庫,mysql官方提供了一些測試資料庫,...