text
Running batch task batching is required in order to take out the primary key, the statement is as follows:
SELECT id FROM foo.bar LIMIT 10 OFFSET 0
+-----+
| id |
+-----+
| 109 |
| 13 |
| 14 |
| 15 |
| 128 |
| 129 |
| 130 |
| 190 |
| 226 |
| 227 |
+-----+
复制代码Found that while using the primary key to the investigation, but the results are not sorted by the primary key.
* Try Query
SELECT * FROM foo.bar LIMIT 10 OFFSET 0
+----+-------+---+
| id | a | b |
+----+-------+---+
| 1 | 24274 | 0 |
| 2 | 24274 | 0 |
| 3 | 24274 | 0 |
| 4 | 24274 | 0 |
| 5 | 24274 | 0 |
| 6 | 24274 | 0 |
| 7 | 24274 | 0 |
| 8 | 24274 | 0 |
| 9 | 24274 | 0 |
| 10 | 24274 | 0 |
+----+-------+---+
复制代码Sorted by the primary key.
View the execution plan, results are as follows:
EXPLAIN SELECT * FROM foo.bar LIMIT 10 OFFSET 0 \G
***************************[ 1. row ]***************************
id | 1
select_type | SIMPLE
table | bar
partitions | <null>
type | ALL
possible_keys | <null>
key | <null>
key_len | <null>
ref | <null>
rows | 211
filtered | 100.0
Extra | <null>
复制代码Select * did not take the index found, use a full table scan, so the order of the primary key order.
EXPLAIN SELECT id FROM foo.bar LIMIT 10 OFFSET 0 \G
***************************[ 1. row ]***************************
id | 1
select_type | SIMPLE
table | bar
partitions | <null>
type | index
possible_keys | <null>
key | idx_a
key_len | 8
ref | <null>
rows | 211
filtered | 100.0
Extra | Using index
复制代码The select id did not use a clustered index. innodb two indexes are automatically added as the primary key index of a last column, it can be done using the index covers the query. The query optimizer uses the index, resulting in the return of the order does not meet expectations.
SELECT a,id FROM foo.bar LIMIT 10 OFFSET 0
+------+-----+
| a | id |
+------+-----+
| 1004 | 109 |
| 1823 | 13 |
| 1823 | 14 |
| 1823 | 15 |
| 1823 | 128 |
| 1823 | 129 |
| 1823 | 130 |
| 1823 | 190 |
| 1823 | 226 |
| 1823 | 227 |
+------+-----+
复制代码Indeed found before a select id index is used, and in accordance with a, the ID order.
SELECT id FROM foo.bar FORCE INDEX(PRI) LIMIT 10 OFFSET 0
+----+
| id |
+----+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 7 |
| 8 |
| 9 |
| 10 |
+----+
复制代码Mandatory use of the primary key index, really no problem.
explain SELECT id FROM boss_business.boss_block_refund_order order by id LIMIT 10 OFFSET 0 \G
***************************[ 1. row ]***************************
id | 1
select_type | SIMPLE
table | boss_block_refund_order
partitions | <null>
type | index
possible_keys | <null>
key | PRIMARY
key_len | 8
ref | <null>
rows | 10
filtered | 100.0
Extra | Using index
复制代码Order by id guide or use the query optimizer may use the primary key index.
Also note, MyISAM table without any engine to delete, modify operation under execution select without order by, it will be sorted by insertion order. Because the use of the index information table would additionally stored MyISAM storage engine to another is called a file of the index file. In short Mysql query optimizer will tend to use the most optimal way.