關於mysql中limit最佳化的問題
一個關於mysql中limit最佳化的問題
| stest | CREATE TABLE `stest` (
`id` int(10) unsigned NOT NULL,
`k` int(10) unsigned NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
第一條測試語句
mysql> select * from stest where id>=(select id from stest order by id asc limi
t 900000,1) limit 50;
50 rows in set (2.58 sec)
第二條測試語句
mysql> select * from stest order by id asc limit 900000,50;
50 rows in set (2.53 sec)
按道理來說第一條應該比第二條查詢要快。。[@more@]
# 建立測試環境:
MYSQL:5。1。40
RHEL 5u4
CREATE TABLE `heyftest` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(30) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4980635 DEFAULT CHARSET=utf8
insert into heyftest(name) values ('zzzzzzzzzzzzzzzzzzzzzzzzz');
insert into heyftest(name) select name from heyftest;
重複很多次,以便資料達到:
: test 12:41:35> select count(*) from heyftest;
+----------+
| count(*) |
+----------+
| 2097408 |
+----------+
1 row in set (0.54 sec)
# 從執行計劃來分析:
explain extended select * from heyftest where id>=(select id from heyftest order by id asc limit 900000,1) limit 50;
+----+-------------+----------+-------+---------------+---------+---------+------+---------+----------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+----------+-------+---------------+---------+---------+------+---------+----------+-------------+
| 1 | PRIMARY | heyftest | range | PRIMARY | PRIMARY | 4 | NULL | 1048908 | 100.00 | Using where |
| 2 | SUBQUERY | heyftest | index | NULL | PRIMARY | 4 | NULL | 900001 | 233.09 | Using index |
+----+-------------+----------+-------+---------------+---------+---------+------+---------+----------+-------------+
先透過子查詢中,找到第900001行,
然後再透過主鍵去RANGE訪問,但這裡ROWS=1048908,有點不理解??? 因為我只想要50行而已,
: test 12:58:23> explain extended select * from heyftest order by id asc limit 900000,50;
+----+-------------+----------+-------+---------------+---------+---------+------+--------+----------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+----------+-------+---------------+---------+---------+------+--------+----------+-------+
| 1 | SIMPLE | heyftest | index | NULL | PRIMARY | 4 | NULL | 900050 | 233.08 | |
+----+-------------+----------+-------+---------------+---------+---------+------+--------+----------+-------+
ROW=900050,可以理解,從第一行開始掃描,在索引裡一直加到900000+50
# 從邏輯讀來分析:
邏輯讀,LIO =兩次Innodb_buffer_pool_read_requests之差
這個測試儘量讓表的所有內容都能在INNODB_BUFFER裡,以避免有物理IO,這樣我們拿到的資料會準一些;
所以測試之前請執行:select count(distinct name) from heyftest;
: test 13:23:05> reset query cache ;
Query OK, 0 rows affected (0.00 sec)
: test 13:23:06> show status like 'Innodb_buffer_pool_read_requests';
+----------------------------------+----------+
| Variable_name | Value |
+----------------------------------+----------+
| Innodb_buffer_pool_read_requests | 57953539 |
+----------------------------------+----------+
1 row in set (0.01 sec)
: test 13:23:06> select * from heyftest where id>=(select id from heyftest order by id asc limit 900000,1) limit 50;
show status like 'Innodb_buffer_pool_read_requests';
+---------+----------------------------+
| id | name |
+---------+----------------------------+
| 2324111 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324113 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324115 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324117 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324119 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324121 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324123 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324125 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324127 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324129 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324131 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324133 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324135 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324137 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324139 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324141 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324143 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324145 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324147 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324149 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324151 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324153 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324155 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324157 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324159 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324161 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324163 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324165 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324167 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324169 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324171 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324173 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324175 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324177 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324179 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324181 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324183 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324185 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324187 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324189 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324191 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324193 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324195 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324197 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324199 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324201 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324203 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324205 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324207 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
| 2324209 | zzzzzzzzzzzzzzzzzzzzzzzzzz |
+---------+----------------------------+
50 rows in set (0.61 sec)
: test 13:23:06> show status like 'Innodb_buffer_pool_read_requests';
+----------------------------------+----------+
| Variable_name | Value |
+----------------------------------+----------+
| Innodb_buffer_pool_read_requests | 58856559 |
+----------------------------------+----------+
1 row in set (0.00 sec)
: test 13:23:06> select 58856559-57953539;
+-------------------+
| 57953539-58856559 |
+-------------------+
| 903020 |
+-------------------+
1 row in set (0.00 sec)
LIO:903020
我們都用上面這種方法來測試,對SQL語句得到的邏輯讀對應如下:
SQL1:select * from heyftest where id>=(select id from heyftest order by id asc limit 900000,1) limit 50;
LIO:903020
SQL2:select * from heyftest order by id asc limit 900000,50;
LIO:115503
SQL4:select id from heyftest order by id asc limit 900000,1; -- 結果:2324111
LIO:115497
SQL5:select * from heyftest where id>=2324111 limit 50;
LIO:26
其實我們認為SQL1的理想計劃是=SQL4+SQL5,其實即使這樣, 115497+26 > 115503, 所以這裡先否掉樓主的想法。
而實際上我們看到MYSQL沒有與我們想像的一樣去把SQL拆分成SQL4,SQL5,
從SQL1 邏輯讀看LIO:903020, 從執行計劃看,ROWS=1048908
這裡是一個奇怪的地方???
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/703656/viewspace-1036812/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 關於mysql 子查詢中 使用 limitMySqlMIT
- 關於 mysql 中的 rand () 查詢問題MySql
- 最佳化mysql的limit offset的例子MySqlMIT
- 關於mysql連線的問題MySql
- 【Mysql】關於mysql存入emoji表情的問題MySql
- 你知道MySQL的Limit有效能問題嗎MySqlMIT
- MySQL LIMIT 和 ORDER BY 最佳化MySqlMIT
- 關於mysql的最佳化MySql
- MySQL中limit的用法MySqlMIT
- 關於mysql5.6 的排序問題.MySql排序
- MySQL中鎖的相關問題DTQUMySql
- MySQL關於事務常見的問題MySql
- 關於mysql的Too many connections問題MySql
- MySQL主從複製中關於AUTO_INCREMENT的奇怪問題MySqlREM
- 關於工作中遇到的問題
- 關於cuda中的函式問題函式
- 關於 iOS 10 中 ATS 的問題iOS
- 關於struts中html:errors/的問題HTMLError
- 關於 mysql 中的 select * from table_a,table_b 的問題MySql
- 【Mysql】關於一個mysql的坑比時區問題MySql
- 關於 Homestead 連線 MySQL 問題MySql
- MySQL order by limit 分頁資料重複問題MySqlMIT
- 關於一個網友最佳化問題的解決
- MySQL:關於排序order by limit值不穩定的說明(1)MySql排序MIT
- CV關於Mysql中ON與Where區別問題詳解buaMySql
- 關於 Laravel 中 Ajax 問題的小結Laravel
- 關於iOS10中ATS的問題iOS
- java中關於Map的九大問題Java
- 關於考勤模組中設計的問題
- 關於jsp中轉發的問題JS
- 急問:關於servlet中得session問題ServletSession
- 關於 mysql相關的jar影響了tomcat 的問題MySqlJARTomcat
- 關於幾個MySQL環境問題的對比MySql
- 關於mysql和jsp的中文問題~謝謝MySqlJS
- 關於XAMPP中Apache和Mysql因埠占用無法啟動的問題ApacheMySql
- Elasticsearch中關於transform的一個問題分析ElasticsearchORM
- 關於頁面中彈窗的定位問題
- 關於QGraphicsView中的物件移動問題. zView物件