- 工信部備案號 滇ICP備05000110號-1
- 滇公安備案 滇53010302000111
- 增值電信業(yè)務(wù)經(jīng)營(yíng)許可證 B1.B2-20181647、滇B1.B2-20190004
- 云南互聯(lián)網(wǎng)協(xié)會(huì )理事單位
- 安全聯(lián)盟認證網(wǎng)站身份V標記
- 域名注冊服務(wù)機構許可:滇D3-20230001
- 代理域名注冊服務(wù)機構:新網(wǎng)數碼
mysql數據量大時(shí)使用limit分頁(yè),隨著(zhù)頁(yè)碼的增大,查詢(xún)效率越低下。
實(shí)驗
1.直接使用用limit start, count分頁(yè)語(yǔ)句:
select * from order limit start, count
當起始頁(yè)較小時(shí),查詢(xún)沒(méi)有性能問(wèn)題,我們分別看下從10, 100, 1000, 10000開(kāi)始分頁(yè)的執行時(shí)間(每頁(yè)取20條), 如下:
1 2 3 4 5 6 7 | select * from order limit 10, 20 0.016秒 select * from order limit 100, 20 0.016秒 select * from order limit 1000, 20 0.047秒 select * from order limit 10000, 20 0.094秒 |
我們已經(jīng)看出隨著(zhù)起始記錄的增加,時(shí)間也隨著(zhù)增大, 這說(shuō)明分頁(yè)語(yǔ)句limit跟起始頁(yè)碼是有很大關(guān)系的,那么我們把起始記錄改為40w看下
select * from order limit 400000, 20 3.229秒
再看我們取最后一頁(yè)記錄的時(shí)間
select * from order limit 800000, 20 37.44秒
顯然這種時(shí)間是無(wú)法忍受的。
從中我們也能總結出兩件事情:
1)limit語(yǔ)句的查詢(xún)時(shí)間與起始記錄的位置成正比
2)mysql的limit語(yǔ)句是很方便,但是對記錄很多的表并不適合直接使用。
2.對limit分頁(yè)問(wèn)題的性能優(yōu)化方法
利用表的覆蓋索引來(lái)加速分頁(yè)查詢(xún)
我們都知道,利用了索引查詢(xún)的語(yǔ)句中如果只包含了那個(gè)索引列(覆蓋索引),那么這種情況會(huì )查詢(xún)很快。
因為利用索引查找有優(yōu)化算法,且數據就在查詢(xún)索引上面,不用再去找相關(guān)的數據地址了,這樣節省了很多時(shí)間。另外Mysql中也有相關(guān)的索引緩存,在并發(fā)高的時(shí)候利用緩存就效果更好了。
在我們的例子中,我們知道id字段是主鍵,自然就包含了默認的主鍵索引?,F在讓我們看看利用覆蓋索引的查詢(xún)效果如何:
這次我們之間查詢(xún)最后一頁(yè)的數據(利用覆蓋索引,只包含id列),如下:
select id from order limit 800000, 20 0.2秒
相對于查詢(xún)了所有列的37.44秒,提升了大概100多倍的速度
那么如果我們也要查詢(xún)所有列,有兩種方法,一種是id>=的形式,另一種就是利用join,看下實(shí)際情況:
SELECT * FROM order WHERE ID > =(select id from order limit 800000, 1) limit 20
查詢(xún)時(shí)間為0.2秒,簡(jiǎn)直是一個(gè)質(zhì)的飛躍啊,哈哈
另一種寫(xiě)法
SELECT * FROM order a JOIN (select id from order limit 800000, 20) b ON a.ID = b.id
查詢(xún)時(shí)間也很短
售前咨詢(xún)
售后咨詢(xún)
備案咨詢(xún)
二維碼
TOP