1. 程式人生 > >MySql 分頁SQL 大資料量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.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 適應場景: 適用於資料量較少的情況(元組百/千級) 原因/缺點: 全表掃描,速度會很慢 且 有的資料庫結果集返回不穩定(如某次返回