MySql 分頁SQL 大資料量limit替代和優化(試驗)
執行結果:select SQL_NO_CACHE u.id, u.user_id, u.user_name, u.user_name_index, u.email, u.pwd, u.email_token, u.email_active_date, u.real_name, u.real_name_index, u.identity_card, u.identity_card_index from t_user u ORDER BY u.id LIMIT 100000, 100; -- 試驗方法1 select SQL_NO_CACHE u.id, u.user_id, u.user_name, u.user_name_index, u.email, u.pwd, u.email_token, u.email_active_date, u.real_name, u.real_name_index, u.identity_card, u.identity_card_index from t_user u where u.id in ( select t.id from (select id from t_user_basic_info order by id limit 100000,100) t ); -- 試驗方法2 -- EXPLAIN select SQL_NO_CACHE u.id, u.user_id, u.user_name, u.user_name_index, u.email, u.pwd, u.email_token, u.email_active_date, u.real_name, u.real_name_index, u.identity_card, u.identity_card_index from t_user u inner join (select id from t_user_basic_info order by id limit 100000,100) as t USING(id) ; -- 試驗方法3 -- EXPLAIN select SQL_NO_CACHE u.id, u.user_id, u.user_name, u.user_name_index, u.email, u.pwd, u.email_token, u.email_active_date, u.real_name, u.real_name_index, u.identity_card, u.identity_card_index from t_user u where u.id >= (select id from t_user_basic_info order by id limit 100000,1) order by id limit 100 ;
[SQL]
select SQL_NO_CACHE
u.id, u.user_id, u.user_name, u.user_name_index, u.email, u.pwd, u.email_token, u.email_active_date,
u.real_name, u.real_name_index, u.identity_card, u.identity_card_index
from t_user u
ORDER BY u.id
LIMIT 100000, 100;
受影響的行: 0
時間: 0.069s
[SQL]
select SQL_NO_CACHE
u.id, u.user_id, u.user_name, u.user_name_index, u.email, u.pwd, u.email_token, u.email_active_date,
u.real_name, u.real_name_index, u.identity_card, u.identity_card_index
from t_user u
where u.id in (
select t.id from (select id from t_user_basic_info order by id limit 100000,100) t
);
受影響的行: 0
時間: 0.119s
[SQL]
-- EXPLAIN
select SQL_NO_CACHE
u.id, u.user_id, u.user_name, u.user_name_index, u.email, u.pwd, u.email_token, u.email_active_date,
u.real_name, u.real_name_index, u.identity_card, u.identity_card_index
from t_user u
inner join (select id from t_user_basic_info order by id limit 100000,100) as t USING(id)
;
受影響的行: 0
時間: 0.034s
[SQL]
-- EXPLAIN
select SQL_NO_CACHE
u.id, u.user_id, u.user_name, u.user_name_index, u.email, u.pwd, u.email_token, u.email_active_date,
u.real_name, u.real_name_index, u.identity_card, u.identity_card_index
from t_user u
where u.id >= (select id from t_user_basic_info order by id limit 100000,1)
order by id
limit 100
;
受影響的行: 0
時間: 0.099s
方案1和3,,速度竟然都不如原生limit,試驗表資料樣本也就十多萬條,有機會用百萬千萬級別來測試。。
相關推薦
MySql 分頁SQL 大資料量limit替代和優化(試驗)
select SQL_NO_CACHE u.id, u.user_id, u.user_name, u.user_name_index, u.email, u.pwd, u.email_token, u.email_active_date, u.
採用Kettle分頁處理大資料量抽取任務
需求: 將Oracle資料庫中某張表歷史資料匯入MySQL的一張表裡面。 源表(Oracle):table1 目標表(MySQL):table2 資料量:20,000,000 思路: 由於伺服器記憶體
SQL大資料量分頁效能優化
目前在進行web api只讀介面的改造,在改造過程中,發現改在後響應時間和之前區別不是很大,通過測試結果顯示在sql的分頁功能處找到原因,並對其進行優化,優化方案如下。測試內容此次執行時間對比採用平臺資金記錄最多的使用者 user_id 36062測試次數未5次 為避免索引
利用MySQL資料庫如何解決大資料量儲存問題?
一、概述 分表是個目前算是比較炒的比較流行的概念,特別是在大負載的情況下,分表是一個良好分散資料庫壓力的好方法。 首先要了解為什麼要分表,分表的好處是什麼。我們先來大概瞭解以下一個資料庫執行SQL的過程: 接收到SQL --> 放入SQL執行佇列 --> 使用分析器分解SQL -->
Oracle PL/SQL 大資料量資料生成器
本內容是臨時本人自己操作出來總結,如有疑問或者不足,請指出,畢竟我也是新手,不可能沒有錯。 在開發測試中,可能對資料庫表裡需要增加多條資料,而傳統insert語句批量可能達不到你想要的效果,於是就可以利用本文講到的PL/SQL的資料生成器,位置如圖。 表的位置
MYSQL(分表)千萬級資料量的優化方法積累
1、分庫分表 一個主表(例如使用者表)無限制的增長勢必嚴重影響效能,分庫與分表是一個很不錯的解決途徑,也就是效能優化途徑,現在的案例是我們有一個1000多萬條記錄的使用者表members,查詢起來非常之慢,同事的做法是將其雜湊到100個表中,分別從members0到me
MySql 大資料量快速插入和語句優化
INSERT語句的速度 插入一個記錄需要的時間由下列因素組成,其中的數字表示大約比例:連線:(3) 傳送查詢給伺服器:(2) 分析查詢:(2) 插入記錄:(1x記錄大小) 插入索引:(1x索引) 關閉:(1) 這不考慮開啟表的初始開銷,每個併發執行的查詢開啟。
大資料量表的查詢優化及索引使用
一、對於運算邏輯,儘可能將要統計的各專案整合在一個查詢語句中計算,而不是用分組條件或分專案呼叫多個查詢語句,而後在程式碼裡計算結果。 二、查詢語句的優化,諸如不用"select *"、多表關聯查詢時新增別名於查詢欄位上、避免使用in、not in關鍵字、非去除重複時用union all替換uni
java excel大資料量匯入匯出與優化
package com.hundsun.ta.utils; import java.io.File; import java.io.FileOutputStream; import java.io.IOException; import java.io.InputStream; import java
大資料量JSONObject.fromObject效能問題(大資料傳給前臺)
最近專案中我負責了一個jms列印log資訊的功能模組。大體需求是,用jms接受log資訊,然後前臺請求的時候,發給前臺最新的log資訊,前臺會不斷的重新整理獲取資料。 個人思路是寫一個靜態的固定長度的list儲存log資訊,如果list滿了清空。前臺第一次訪問的時候,返回給
ArcSDE for Oracle在大資料量執行建立統計資訊(Analyze)耗時長的問題
Article ID:42983Software: ArcSDE 10.1, 10.2, 10.2.1, 10.2.2 ArcGIS for Desktop Advanced 10.1, 10.2, 10.2.1, 10.2.2, 10.1 SP1, 10.3 ArcGIS
大資料量下查詢顯示優化方案小結
# 大資料量下查詢顯示優化方案小結 # 最近工作中,遇到了優化大批量資料查詢和顯示的問題,資料量在10W級別。經過反覆設計和討論,最終得到優化到了較為滿意的效果,在此記錄小結下,在解決此類問題中的思考。 ## 問題背景說明 ## 通常情況下,使用者查詢資料量不超過1千條,但有幾個大戶,通過某種方式,生成
從MySQL Bug#67718淺談B+樹索引的分裂優化(轉)
原文連結:http://hedengcheng.com/?p=525 問題背景 今天,看到Twitter的DBA團隊釋出了其最新的MySQL分支:Changes in Twitter MySQL 5.5.28.t9,此分支最重要的一個改進,就是修復了MySQL 的Bug #67718:In
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分頁,資料量大時limit優化
MYSQL的優化是非常重要的。其他最常用也最需要優化的就是limit。mysql的limit給分頁帶來了極大的方便,但資料量一大的時候,limit的效能就急劇下降。 同樣是取10條資料 select * from order limit 10000,10 select * from or
mysql limit做分頁查詢的優化(大資料量)
mysql limit查詢優化,由於limit經常用到,卻沒有注意,因為平時做的專案都比較小,所以也沒有考慮去怎麼優化,MYSQL的優化是非常重要的。其他最常用也最需要優化的就是limit。mysql的limit給分頁帶來了極大的方便,但資料量一大的時候,limit的效能就急
MySQL大資料量分頁SQL語句優化
分頁程式原理很簡單,這裡就不多說了,本篇文章主要說的是在資料表記錄量比較大的情況下,如何將分頁SQL做到更優化,讓MySQL執行的更快的方法。 一般的情況下,我們的分頁SQL語句是這樣的:
MySQL大資料量分頁查詢方法及其優化 MySQL大資料量分頁查詢方法及其優化
MySQL大資料量分頁查詢方法及其優化 ---方法1: 直接使用資料庫提供的SQL語句---語句樣式: MySQL中,可用如下方法: SELECT * FROM 表名稱 LIMIT M,N ---適應場景: 適用於資料量較少的情況(元組百/千級) --
mysql 大資料量分頁優化
假設有一個千萬量級的表,取1到10條資料; select * from table limit 0,10; select * from table limit 1000,10; 這兩條語句查詢時間應該在毫秒級完成; select * from table limit
MySQL大資料量分頁查詢方法及其優化
方法1: 直接使用資料庫提供的SQL語句 語句樣式: MySQL中,可用如下方法: SELECT * FROM 表名稱 LIMIT M,N 適應場景: 適用於資料量較少的情況(元組百/千級) 原因/缺點: 全表掃描,速度會很慢 且 有的資料庫結果集返回不穩定(如某次返回