MySQL高效分頁解決方案集
原文:http://blog.csdn.net/lyd518/article/details/12444153
一,最常見MYSQL最基本的分頁方式:
select * from content order by id desc limit 0, 10
在中小資料量的情況下,這樣的SQL足夠用了,唯一需要注意的問題就是確保使用了索引。隨著資料量的增加,頁數會越來越多,檢視後幾頁的SQL就可能類似:
select * from content order by id desc limit 10000, 10
一言以蔽之,就是越往後分頁,LIMIT語句的偏移量就會越大,速度也會明顯變慢。
此時,我們可以通過2種方式:
一,子查詢的分頁方式來提高分頁效率,飄易用的SQL語句如下:
SELECT * FROM `content` WHERE id (SELECT id FROM `content` ORDER BY id desc LIMIT ".($page-1)*$pagesize.", 1) ORDER BY id desc LIMIT $pagesize
為什麼會這樣呢?因為子查詢是在索引上完成的,而普通的查詢時在資料檔案上完成的,通常來說,索引檔案要比資料檔案小得多,所以操作起來也會更有效率。(via)通過explain SQL語句發現:子查詢使用了索引!
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY content range PRIMARY PRIMARY 4 NULL 6264 Using where
2 SUBQUERY content index NULL PRIMARY 4 NULL 27085 Using index
經過飄易的實測,使用子查詢的分頁方式的效率比純LIMIT提高了14-20倍!
二,JOIN分頁方式
select * FROM `content` AS t1
JOIN (SELECT id FROM `content` ORDER BY id desc LIMIT ".($page-1)*$pagesize.", 1) AS t2
WHERE t1.id
經過我的測試,join分頁和子查詢分頁的效率基本在一個等級上,消耗的時間也基本一致。explain SQL語句:
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY system NULL NULL NULL NULL 1
1 PRIMARY t1 range PRIMARY PRIMARY 4 NULL 6264 Using where
2 DERIVED content index NULL PRIMARY 4 NULL 27085 Using index
三,使用MYSQL的FOUND_ROWS()函式
Mysql FOUND_ROWS() 函式結合SQL_CALC_FOUND_ROWS在SELECT中可以得到兩個結果:
1. 得到Limit的內容
2. 得到去除Limit以後所有行數
SELECT語句中經常可能用LIMIT限制返回行數。有時候可能想要知道如果沒有LIMIT會返回多少行,但又不想再執行一次相同語句。那麼,在SELECT查詢中包含SQL_CALC_FOUND_ROWS選項,然後執行FOUND_ROWS()就可以了:
select SQL_CALC_FOUND_ROWS * FROM tbl_name WHERE id > 100 LIMIT 10;
SELECT FOUND_ROWS();
其中SQL_CALC_FOUND_ROWS 告訴Mysql將sql所處理的行數記錄下來,FOUND_ROWS() 則取到了這個紀錄。 雖然也是兩個語句,但是隻執行了一次主查詢,所以效率比原來要高很多。
1. 如果在前一條語句中使用SQL_CALC_FOUND_ROWS選項,FOUND_ROWS()將返回第一條語句沒有LIMIT時返回的行數。
2. 如果在前一條語句中沒有使用SQL_CALC_FOUND_ROWS選項,FOUND_ROWS()將返回前一條語句實際返回的行數。
如果使用 SELECT SQL_CALC_FOUND_ROWS,MySQL必須計算所有結果集的行數。儘管這樣,總比再執行一次不使用LIMIT的查詢要快多了吧,因為那樣結果集要返回客戶端滴。(另外:應該不單是沒有將結果集返回的原因,還有原因可能是比如LIKE之類比較費勁的SQL不需要再去勞累一次。)
-- 注意下面語句中的條件 LIKE
SELECT SQL_CALC_FOUND_ROWS * FROM tbl_name WHERE Name LIKE '%string%' id > 100 LIMIT 10;
SELECT FOUND_ROWS();
-- 上面語句等價於下面語句,但效能方面應該提升非常非常的明顯:
SELECT COUNT(*) FROM tbl_name WHERE Name LIKE '%string%' ;
SELECT * FROM tbl_name WHERE Name LIKE '%string%' id > 100 LIMIT 10;
相關文章
- MySQL高效分頁解決方案集(轉)MySql
- MySQL字符集亂碼與解決方案MySql
- Openstack的HA解決方案【mysql叢集配置】MySql
- 如何高效分頁
- 高效實現MySQL資料整合至金蝶雲星空的解決方案MySql
- JS 網頁列印解決方案JS網頁
- 查詢效率提升10倍!3種優化方案,幫你解決MySQL深分頁問題優化MySql
- mysql壓縮解決方案MySql
- mysql分頁-limit offset分頁MySqlMIT
- .NET 中高效 Excel 解決方案 MiniExcelExcel
- 高效能運算GPU解決方案系列教程二–高效能運算叢集效能指標GPU指標
- HBase海量資料高效入倉解決方案
- 分散式互斥的高效容錯解決方案分散式
- 分庫解決方案—實際操作
- 機械行業解決方案高效解決企業管理難題行業
- Redis Sentinel:叢集Failover解決方案RedisAI
- 使用MySQL的遞延Join連線實現高效分頁 - AaronMySql
- 禁止web頁面縮放解決方案Web
- WinForm嵌入Web網頁的解決方案ORMWeb網頁
- iframe父子頁面通訊解決方案
- iOS 高效的分頁載入iOS
- Mysql分庫分表方案MySql
- MySQL解除安裝重灌解決方案MySql
- mysql忘記密碼解決方案MySql密碼
- mysql密碼忘記解決方案MySql密碼
- MySQL大表刪除解決方案MySql
- MySQL server has gone away 解決方案MySqlServerGo
- MySQL Drop 大表的解決方案MySql
- 億萬級資料處理的高效解決方案
- 高效IO解決方案-Mmap「給你想要的快」
- .NET 高效靈活的API速率限制解決方案API
- Rownum分頁故障解決一例
- 24-PHP+MySQL分頁技術詳解PHPMySql
- 分詞,難在哪裡?科普+解決方案!分詞
- 分庫解決方案—資料儲存
- 【基礎知識思考整理 】Mysql高效率的分頁查詢MySql
- 解決MySQL server has gone away錯誤的解決方案MySqlServerGo
- MySQL、Elasticsearch 深度分頁MySqlElasticsearch