MySQL大資料下Limit使用

來源:互聯網
上載者:User

標籤:大資料   索引   最佳化   mysql   limit   

對於一直用Oracle的我,今天可是非常詫異,MySQL中同一個函數在不同數量級上的效能居然差距如此之大。

先看錶ibmng(id,title,info)  唯一  id key 索引title

先看看兩條語句:

select * from ibmng limit 1000000,10
select * from ibmng limit 10,10

很多人都會認為不會有多大差別,但是他們都錯了,差別太大了,(可能機器不同有點差距,但絕對10倍以上)具體執行時間留給好奇的同學。

這是為什麼呢,都是offset的錯!

最佳化的話你可以想方法減小offset,如以下:

Select * From ibmng Where id >=(
  Select id From ibmng Order By id limit 1000000,1
) limit 10

大家一定會看到問題, limit 1000000,1 同樣offset不是一樣大嗎,肯定不能最佳化。(但是,又錯了,執行之後才知道結果!)

原因是id是索引,所有快,那麼如下sql呢:

select id from ibmng where title=‘mysql‘ order by id limit 1000000,10; 

這條sql大家又會猜錯,同樣慢的跟蝸牛一樣。(在此大家都會想title加了索引啊怎麼會這樣!)

接下來大家再執行一條sql如下:

select id from ibmng where title=‘mysql‘ limit 1000000,10; 

執行之後你會發現速度是sousou的快!

原因看出來了吧,都是用了索引的原因,如果你要用select id from ibmng where title=‘mysql‘ order by id limit 1000000,10; 那麼就追加複合索引(title,id )吧!

注意:接下來與limit無關!

最後回到我現在的情境,如果千萬層級的資料分批次讀取統計的話,不要使用limit最好,用主鍵範圍判斷最佳!(eg:id<=1001000 and id>=1000001)

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.