MySQL以DESC顺序比ASC顺序查询更快

Question

I made a simple database (innodb version 5.7.9) with 2 tables, post and post_tag.

Post has a single field ID (big int) set as Primary key (about 120,000 entries). Post_tag has 2 fields, post_id (big int) and tag_id (int), and the primary key is on [post_id, tag_id].

The following query runs in ~1ms:

SELECT 
   SQL_NO_CACHE p.id 
FROM 
   post as p 
STRAIGHT_JOIN 
   post_tag t
WHERE  
   t.post_id = p.id AND t.tag_id = 25 
ORDER BY 
   p.id DESC
LIMIT 0, 100

But if I change the ORDER BY to ASC, it runs about 100 times slower! And that the sort I am interested into...

Any idea why?

Initially, I wanted the IDs sorted DESC, and I noticed it was slower than ASC. I read that the natural sort for index is ASC, so I reverted all the ID (by doing ID = SOMETHING BIG - ID), but then it didn't changed anything as it's now slower in ASC.

I uploaded the database here in case it's useful.

Many thanks in advance to anyone who can help.

And here is the explain:

Answer 1

If there are "other constraints", then all bets are off.

Meanwhile, looking at what you have...

STRAIGHT_JOIN , USE INDEX , etc, are crutches for when (a) you don't have the 'right' index, or (b) the optimizer can't figure out the 'right' thing to do. That is, look for other solutions.

In your example, you would be better of with a plain JOIN and INDEX(tag_id, post_id) . This would let it go to post_tag first since there is a WHERE clause letting it filter there. The optimizer will probably see that t.post_id and p.id are identical, so start a the end (for DESC ) of (25, post_id) in the index, and scan. It then checks to see if there is a post entry (that being the only apparent use for post -- again if there are "other constraints", all bets are off).

So, back to the original question. STRAIGHT_JOIN forced looking in post first. But where are the 25s? Apparently near the end of post_tag . Hence, ASC took longer to find 100 (see LIMIT ) of them than if the scan started at the other end!

Assuming this is a many-to-many mapping table, do this:

CREATE TABLE post_tag (
    post_id ...,
    tag_id ...,
    PRIMARY KEY(post_id, tag_id),
    INDEX      (tag_id, post_id)
) ENGINE=InnoDB;

I discuss the many reasons in my blog .

If, as was suggested, you add (tag_id, post_id DESC) , don't be deluded into thinking that the DESC means anything -- it is recognized, but ignored. Both parts will be stored ASC . What will happen is that the Optimizer is smart enough to start at the end of the 25s and scan backward. Here's "proof":

US has INDEX(state, population) :

mysql> FLUSH STATUS;
mysql> SELECT city, population FROM US
          WHERE state = 'OH'
          ORDER BY population DESC LIMIT 5;
+------------+------------+
| city       | population |
+------------+------------+
| Columbus   |     736836 |
| Cleveland  |     449514 |
| Toledo     |     306974 |
| Cincinnati |     306382 |
| Akron      |     208414 |
+------------+------------+
mysql> SHOW SESSION STATUS LIKE 'Handler%';
| Handler_read_key           | 1     |  -- get started at end of Ohio
| Handler_read_prev          | 4     |  -- read (5-1) more, scanning backwards

The only case where MySQL is missing the boat by ignoring DESC in an INDEX declaration is: ORDER BY a ASC, b DESC cannot use INDEX(a,b) .

Answer 2

Presumably, you have an index on post(id) (this is created automatically for primary keys, for instance). MySQL sometimes pays attention to the order of the index when using an index for ORDER BY .

By changing the order, you are changing the query plan in such a way that sorting is necessary.

I would suggest writing the query using only one table:

SELECT t.post_id 
FROM post_tag t
WHERE t.tag_id = 25 
ORDER BY t.post_id DESC
LIMIT 0, 100;

The JOIN is not necessary for this query, assuming that all values of post_id refer to valid posts (which seems like a very reasonable assumption).

For this query, an index on post_tag(tag_id, post_id desc) is optimal, and MySQL might do the right thing for a descending sort.