When the subselect runs faster (zt)

最新推荐文章于 2021-02-11 11:41:23 发布

最新推荐文章于 2021-02-11 11:41:23 发布 · 97 阅读

文章标签：

#MySQL #REST #performance #Cache #F#

Databases 专栏收录该内容

7 篇文章

订阅专栏

本文探讨了一种改进SQL查询性能的方法，通过将原始查询重构为使用子查询与索引，显著提升了查询速度。具体案例展示了如何通过调整查询逻辑和使用FORCEINDEX提示来优化查询性能，特别关注了WHERE子句不具高选择性的情况。这种方法不仅加速了查询过程，还揭示了在特定场景下，子查询并非总是降低性能的原因。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

A few weeks ago, we had a query optimization request from one of our customer.

The query was very simple like:

 PLAIN TEXT

CODE:
   
      SELECT * FROM `table` WHERE 
      (col1=
      'A'||col1=
      'B'
      ) ORDER BY id DESC LIMIT 
      20 OFFSET 
      0 
     

  

This column in the table is looks like this:

 PLAIN TEXT

CODE:
   
      `col1` enum
      (
      'A',
      'B',
      'C',
      'CD',
      'DE',
      'F',
      'G',
      'HI'
      ) default NULL
     

  

The table have 549252 rows and of course, there is an index on the col1. MySQL estimated the cardinality of that index as 87, though what was of course misleading as index cardinality in this case can't be over 9, as there is only 8(+ NULL) different possible values for this column.

 PLAIN TEXT

CODE:
   
      +----+-------------+-------+-------+---------------+------+---------+------+--------+-----------------------------+
     
      | id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows   | Extra                       |
     
      +----+-------------+-------+-------+---------------+------+---------+------+--------+-----------------------------+
     
      |  
      1 | SIMPLE      | table  | range | col1         | col1 | 
      2       | NULL | 
      549252 | Using where; Using filesort |
     
      +----+-------------+-------+-------+---------------+------+---------+------+--------+-----------------------------+

This query took more than 5 minutes (the rows are large and table does not fit in cache well)

When you want to run this query mysql first will try to find each row where col1 is A or B using index. Then its going to order by the ID using file sort and then send first 20 rows ignoring the rest.

In this case MySQL has 2 indexes where one is usable to find rows, while other is usable to return them in the right order. MySQL can chose only one of them to execute the query - use index to find rows. This is sensible strategy if there is no LIMIT, however it is poor chose if there is one - it is often a lot faster to retrieve rows in order checking WHERE clause for them until required number of rows were returned. Especially in the cases when WHERE clause is not very selective.

So I tried this:

 PLAIN TEXT

CODE:
   
      select * from table where id in 
      (SELECT id FROM `table` WHERE 
      (col1=
      'A'||col1=
      'B'
      )
      ) ORDER BY id DESC LIMIT 
      20 OFFSET 
      0;
     

  

In this case we forcing MySQL to do retrieve rows in sorted order and checking if it matches our original WHERE clause with subselects. It looks scary if we look at EXPLAIN but in reality the dependent subquery is only executed enough times to produce 20 rows in result set.

 PLAIN TEXT

CODE:
   
      +----+--------------------+-------+-----------------+---------------+---------+---------+------+--------+-------------+
     
      | id | select_type        | table | type            | possible_keys | key     | key_len | ref  | rows   | Extra       |
     
      +----+--------------------+-------+-----------------+---------------+---------+---------+------+--------+-------------+
     
      |  
      1 | PRIMARY            | table  | index           | NULL          | PRIMARY | 
      4       | NULL | 
      765105 | Using where |
     
      |  
      2 | DEPENDENT SUBQUERY | table  | unique_subquery | PRIMARY,col1  | PRIMARY | 
      4       | func |      
      1 | Using where |
     
      +----+--------------------+-------+-----------------+---------------+---------+---------+------+--------+-------------+

The result is a lot better result time:

 PLAIN TEXT

CODE:
    
      (
      20 rows in set 
      (
      0.
      01 sec
      )
      ) 
     

  

So by rewriting query using subqueries we actually improved it performance 100 times. So subqueries are
not always slowing things down.

Even though proving subqueries are not always slow this way is not the most optimal. We do not really need separate subselect to make MySQL check WHERE clause while scanning table in index order. We can just use FORCE INDEX hint to override MySQL index choice:

 PLAIN TEXT

CODE:
   
      mysql> explain select * from table FORCE INDEX
      (PRIMARY
      ) where 
      (col1=
      'A'||col1=
      'B'
      ) order by id desc limit 
      20 offset 
      0;
     
      +----+-------------+-------+-------+---------------+---------+---------+------+--------+-------------+
     
      | id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows   | Extra       |
     
      +----+-------------+-------+-------+---------------+---------+---------+------+--------+-------------+
     
      |  
      1 | SIMPLE      | table  | index | NULL          | PRIMARY | 
      4       | NULL | 
      549117 | Using where |
     
      +----+-------------+-------+-------+---------------+---------+---------+------+--------+-------------+
     
      mysql> select * from table FORCE INDEX
      (PRIMARY
      ) where 
      (col1=
      'A'||col1=
      'B'
      ) order by id desc limit 
      20 offset 
      0;
     
      ...
     
      20 rows in set 
      (
      0.
      00 sec
      )

This approach works well if WHERE clause is not very selective, otherwise MySQL may need to scan very many rows to find enough matching rows. You can use another trick Peter
wrote. about couple of years ago.