1. 程式人生 > >mysql 大資料量分頁優化

mysql 大資料量分頁優化

假設有一個千萬量級的表,取1到10條資料;

select * from table limit 0,10;

select * from table limit 1000,10;

這兩條語句查詢時間應該在毫秒級完成;

select * from table limit 3000000,10;

你可能沒想到,這條語句執行之間在5s左右;

為什麼相差這麼大?

可能mysql並沒有你想的那麼智慧,比如你要查詢 300w開始後面10條資料;mysql會讀取300w加10條這麼多的資料,只不過 過濾後返回最後10條而已!!!

那麼如果解決這個問題呢;這裡總結三種常用方法;

第一種簡單粗暴,就是不允許檢視這麼靠後的資料,比如百度就是這樣的

最多翻到76頁就不讓你翻了,這種方式就是從業務上解決;

第二種方法,在查詢下一頁時把上一頁的行id作為引數傳遞給客戶端程式,然後sql就改成了

select * from table where id>3000000 limit 10;

這條語句執行也是在毫秒級完成的,id>300w其實就是讓mysql直接跳到這裡了,不用依次在掃描全面所有的行

如果你的table的主鍵id是自增的,並且中間沒有刪除和斷點,那麼還有一種方式,比如100頁的10條資料

select * from table where id>100*10 limit 10;

最後第三種方法:延遲關聯

我們在來分析一下這條語句為什麼慢,慢在哪裡。

select * from table limit 3000000,10;

玄機就處在這個 * 裡面,這個表除了id主鍵肯定還有其他欄位  比如 name  age  之類的,因為select  *  所以mysql在沿著id主鍵走的時候要回行拿資料,走一下拿一下資料;

如果把語句改成 

select id from table limit 3000000,10;

你會發現時間縮短了一半;然後我們在拿id分別去取10條資料就行了;

語句就改成這樣了:

select table.* from table inner join ( select id from table limit 3000000,10 ) as tmp on tmp.id=table.id;

這三種方法最先考慮第一種 其次第二種,第三種是別無選擇

相關推薦

mysql 料量優化

假設有一個千萬量級的表,取1到10條資料; select * from table limit 0,10; select * from table limit 1000,10; 這兩條語句查詢時間應該在毫秒級完成; select * from table limit

MySQL料量查詢方法及其優化 MySQL料量查詢方法及其優化

MySQL大資料量分頁查詢方法及其優化   ---方法1: 直接使用資料庫提供的SQL語句---語句樣式: MySQL中,可用如下方法: SELECT * FROM 表名稱 LIMIT M,N ---適應場景: 適用於資料量較少的情況(元組百/千級) --

MySQL料量查詢方法及其優化 ---方法1: 直接使用資料庫提供的SQL語句 ---語句樣式: MySQL中,可用如下方法: SELECT * FROM 表名稱 LIMIT M,N ---適

測試實驗 1.   直接用limit start, count分頁語句, 也是我程式中用的方法: select * from product limit start, count 當起始頁較小時,查詢沒有效能問題,我們分別看下從10, 100, 1000, 10000開始分頁的執行時間(每頁取20條), 如

MySQL料量查詢方法及其優化

方法1: 直接使用資料庫提供的SQL語句 語句樣式: MySQL中,可用如下方法: SELECT * FROM 表名稱 LIMIT M,N 適應場景: 適用於資料量較少的情況(元組百/千級) 原因/缺點: 全表掃描,速度會很慢 且 有的資料庫結果集返回不穩定(如某次返回

MySQL料量SQL語句優化

分頁程式原理很簡單,這裡就不多說了,本篇文章主要說的是在資料表記錄量比較大的情況下,如何將分頁SQL做到更優化,讓MySQL執行的更快的方法。 一般的情況下,我們的分頁SQL語句是這樣的:

料量優化--延遲查詢

延遲關聯 select * from it_area where name like '%東山%';+------+-----------+------+ | id   | name      | pid  | +------+-----------+------+ |  

SQL料量效能優化

目前在進行web api只讀介面的改造,在改造過程中,發現改在後響應時間和之前區別不是很大,通過測試結果顯示在sql的分頁功能處找到原因,並對其進行優化,優化方案如下。測試內容此次執行時間對比採用平臺資金記錄最多的使用者 user_id 36062測試次數未5次  為避免索引

解決mongodb料量查詢效率問題

最常見的分頁採用的是skip+limit這種組合方式,這種方式對付小資料倒也可以,但是對付上幾百上千萬的大資料,只能力不從心,skip如果跳過大量的資料會很慢,並且會越查越慢,針對這一情況,可以通過條件查詢+排序+限制返回記錄,即 邊查詢,邊排序,排序之後,抽取上一頁中的最後一條記錄,作為當前分

mongodb料量查詢效率問題

最常見的分頁採用的是skip+limit這種組合方式,這種方式對付小資料倒也可以,但是對付上幾百上千萬的大資料,只能力不從心,skip如果跳過大量的資料會很慢,並且會越查越慢。 //程式碼大概看下意思就行了 const list = db.getCollection('se

料量儲存過程效率測試

我首先寫了五個常用儲存過程: 1,利用select top 和select not in進行分頁,具體程式碼如下: CREATE PROCEDURE Proc_paged_with_notin --利用select top and select n

sql2000,千萬級料量儲存過程效率測試附程式碼

在專案中,我們經常遇到或用到分頁,那麼在大資料量(百萬級以上)下,哪種分頁演算法效率最優呢?我們不妨用事實說話。 測試環境 硬體:CPU 酷睿雙核T5750  記憶體:2G 軟體:Windows server 2003    +   Sql server 2005 OK

Displaytag使用與應用displaytag完成料量顯示的例子

Display Tag Lib是一個標籤庫,用來處理jsp網頁上的Table,功能非常強,可以對的Table進行分頁、資料匯出、分組、對列排序等等,反正我在做專案時需要的功能它都給我提供了,而且使用起來非常的方便。能夠大大減少程式碼量。     介個是Display Tag

MySQL料量快速實現

以下分享一點我的經驗 一般剛開始學SQL語句的時候,會這樣寫 程式碼如下: SELECT * FROM table ORDER BY id LIMIT 1000, 10; 但在資料達到百萬級的時候,這樣寫會慢死 程式碼如下: SELECT * FROM tabl

mysql料量優化

1 優化sql和索引2 增加快取如:redis3 主從複製或主主複製,讀寫分離4 利用mysql自帶分割槽表5 先做垂直拆分,將一個大系統分為多個小系統,也就是分散式6 水平切分,要選擇一個合理的sharding key,為了有好的查詢效率,表結構也要改動,做一定的冗餘,應用也要改,sql中儘量帶shardi

MySQL 料量優化方案

單表優化 除非單表資料未來會一直不斷上漲(例如網路爬蟲),否則不要一開始就考慮拆分,拆分會帶來邏輯、部署、運維的各種複雜度 一般以整型值為主的表在 千萬級以下,字串為主的表在 五百萬以下是沒有太大問題的。而事實上很多時候 MySQL 單表的效能依然有不少優化空間,甚至能正

mysql 料量時 limit查詢優化

一般,我們在做分頁時,用的是語句如下:select * from table LIMIT 5,10; #返回第6-15行資料但是,如果資料量很大,比如>1000萬,則利用以上的查詢會非常慢,可以利用以下語句進行優化:Select * From table Where I

MySql 料量快速插入和語句優化

INSERT語句的速度 插入一個記錄需要的時間由下列因素組成,其中的數字表示大約比例:連線:(3) 傳送查詢給伺服器:(2) 分析查詢:(2) 插入記錄:(1x記錄大小) 插入索引:(1x索引) 關閉:(1) 這不考慮開啟表的初始開銷,每個併發執行的查詢開啟。

afs在料量時查詢優化

afs查詢,mule報錯的問題 1.mule報錯的原因 a)mule預設請求響應時間為10s,當請求返回的時間超過10秒就會報錯 2.導致請求時間過長的原因 a)欄位沒有建索引,count(*)統計記錄總數耗時過長(283W記錄統計耗時8-9s) b)一次性請求數量過多(經測試500條資料4

mysql 使用索引進行優化

MySQL大資料量分頁查詢方法及其優化 ---方法1: 直接使用資料庫提供的SQL語句 ---語句樣式: MySQL中,可用如下方法: SELECT * FROM 表名稱 LIMIT M,N ---適應場景: 適用於資料量較少的情況(元組百/千級) ---原因/缺點: 全表掃描,速度會很慢 且

c++程式料量處理效能優化

1. 現在處理的程式為每秒鐘處理20w條資料,甚至更多,加快處理速度,總結了一些經驗,記錄下來程式的資料結構裡面儘量避免string,map這樣的資料結構,因為string雖然不用自己管理指標,但是在構造和析構的時候很費資源,還有在執行c_str()的時候要new出一塊記憶體來