为什么在较少 char 值上过滤的索引 mysql 查询会导致检查更多行？

Question

When I run the following query, I see the expected rows examined as 40

EXPLAIN SELECT s.* FROM subscription s
WHERE s.current_period_end_date <= NOW()
AND s.status in ('A', 'T')
AND s.period_end_action in ('R','C')
ORDER BY s._id ASC limit 20;

+----+-------------+-------+-------+--------------------------------+---------+---------+------+------+-------------+
| id | select_type | table | type  | possible_keys                  | key     | key_len | ref  | rows | Extra       |
+----+-------------+-------+-------+--------------------------------+---------+---------+------+------+-------------+
|  1 | SIMPLE      | s     | index | status,current_period_end_date | PRIMARY | 4       | NULL |   40 | Using where |
+----+-------------+-------+-------+--------------------------------+---------+---------+------+------+-------------+

But when I run this query that simply changes AND s.period_end_action in ('R','C') to AND s.period_end_action = 'C' , I see the expected rows examined as 611

EXPLAIN SELECT s.* FROM subscription s
WHERE s.current_period_end_date <= NOW()
AND s.status in ('A', 'T')
AND s.period_end_action = 'C'
ORDER BY s._id ASC limit 20;

+----+-------------+-------+-------+--------------------------------+---------+---------+------+------+-------------+
| id | select_type | table | type  | possible_keys                  | key     | key_len | ref  | rows | Extra       |
+----+-------------+-------+-------+--------------------------------+---------+---------+------+------+-------------+
|  1 | SIMPLE      | s     | index | status,current_period_end_date | PRIMARY | 4       | NULL |  611 | Using where |
+----+-------------+-------+-------+--------------------------------+---------+---------+------+------+-------------+

I have the following indexes on the subscription table:

_id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
INDEX(status, period_end_action),
INDEX(current_period_end_date),

Any ideas? I don't understand why removing one of the period_end_action values would cause such a large increase in rows examined?

Answer 1

(I agree with others that EXPLAIN often has terrible row estimates.)

Actually the numbers might be reasonable (though I doubt it). The optimizer decided to do a table scan in both cases. And the query with fewer options for period_end_action probably has to scan farther to get the 20 rows. This is because it punted on using either of your secondary indexes.

These indexes are more likely to help your second query:

INDEX(period_end_action, _id)
INDEX(period_end_action, status)
INDEX(period_end_action, current_period_end_date)

The optimal index is usually starts with any columns tested by = .

Since there is no such thing for your first query, the Optimizer probably decided to scan in _id order so that it could avoid the "sort" mandated by ORDER BY .