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出一塊記憶體來