今天遇到開發反應分頁語句很慢,馬上看一下到底是啥的分頁語句
原分頁語句
select * from `tt` limit 4863000, 1000執行這個語句需要6秒+時間
執行計畫為全表掃瞄
在網上看到葉金榮對分頁優化的文章,於是把語句修改為inner join的方式
分頁改為inner join的方式
修改後的語句
修改之後只用了1.6秒
執行計畫
修改之後的語句其實本質沒有變還是掃瞄表得到4863000這個錨點之後的資料,但是仔細觀察你會發現實際上子查詢裡面
只查詢id這一列,因為表本身有乙個最窄索引ind_rsyncs,這個索引只有乙個列rsyncs,利用這個最窄索引掃瞄到4863000之後的id值
id是主鍵,然後子表和主表做join,join條件是id,雖然本質沒有變,但是相比改寫前的語句大大節省了io,所以查詢速度有了質的提公升
select id from `tt` limit 4863000, 1000
mysql分頁優化方法
今天遇到開發反應分頁語句很慢,馬上看一下到底是啥的分頁語句 原分頁語句 select from tt limit 4863000,1000執行這個語句需要6秒 時間 執行計畫為全表掃瞄 在網上看到葉金榮對分頁優化的文章,於是把語句修改為inner join的方式 分頁改為inner join的方式 ...
mysql 修改分頁 mysql分頁優化方法
mysql分頁優化方法 今天遇到開發反應分頁語句很慢,馬上看一下到底是啥的分頁語句 原分頁語句 select from tt limit 4863000,1000 執行這個語句需要6秒 時間 執行計畫為全表掃瞄 在網上看到葉金榮對分頁優化的文章,於是把語句修改為inner join的方式 分頁改為i...
mysql的分頁優化 mysql分頁優化
有個200多萬的使用者表,顯示列表時非常慢,查了一下原來使用了limit進行分頁。前幾頁用時很少 但是後面頁數就簡直不可忍了,實際的業務邏輯還有排序,就更慢了 試試用查詢時用帶索引的鍵來確定範圍。最大的id是103948598 時間和用limit比相差幾千倍啊!使用explain 檢視一下 mysq...