【问题标题】:how to optimize SQL queries using IN having indexed keys如何使用具有索引键的 IN 优化 SQL 查询
【发布时间】:2016-01-05 16:01:26
【问题描述】:

我正在运行这个查询

EXPLAIN SELECT id, timestamp from foo where id IN (23,67,78,90) order by ASC

此处id 已编入索引。但是当我运行Explain 时,我也在Using where;Using Index 中得到这个Extra

+----+-------------+---------------+-------+---------------+---------+---------+------+------+-------------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra       |
+----+-------------+---------------+-------+---------------+---------+---------+------+------+-------------+
|  1 | SIMPLE      | foo   | range | PRIMARY       | PRIMARY | 8       | NULL |   12  | Using where;Using Index|
+----+-------------+---------------+-------+---------------+---------+---------+------+------+-------------+

但是,当我使用单个 id 运行相同的查询时,Extra 中没有任何内容,它在索引的情况下按预期工作

EXPLAIN SELECT id, timestamp from foo where id = 23`

+----+-------------+---------------+-------+---------------+---------+---------+------+------+-------------+
| id | select_type | table| type  | possible_keys | key     | key_len | ref  | rows | Extra       |
+----+-------------+---------------+-------+---------------+---------+---------+------+------+-------------+
|  1 | SIMPLE      | foo | range | PRIMARY       | PRIMARY | 8       | NULL |  1 |        |
+----+-------------+---------------+-------+---------------+---------+---------+------+------+-------------+

我认为 IN 有问题。谁能告诉我优化它的方法?

【问题讨论】:

  • 我很困惑。您认为查询如何在不使用索引对行进行某种搜索的情况下找到这些行?
  • 它说它正在使用索引。这意味着它已经过优化。
  • 又添加了一件事......现在到什么程度会影响执行时间?
  • 发生了一些奇怪的事情——为什么“范围”只是“id=23”。请提供SHOW CREATE TABLE

标签: mysql indexing explain where-in


【解决方案1】:

据我所知,

IN 查询将比单个“=”花费更多时间。如果“IN”只有一个值,那么它等于单个“=”查询。

因为它是“=”或“=”的MULTIPLE OR条件。

id 将匹配 "IN" 数组中的每 4 个值。

Only way to optimise is to have index.

更新:

如果 Extra 列也显示 Using where,则表示该索引正在用于执行键值查找。如果不使用 where,优化器可能会读取索引以避免读取数据行,但不会将其用于查找。例如,如果索引是查询的覆盖索引,优化器可能会扫描它而不使用它进行查找。见explanation

【讨论】:

  • 所有内容都已编入索引,但问题是即使在编入索引后,它仍显示 Using where in extra in expain 它不应该显示 using where
  • 这意味着它不能再优化了
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2012-08-05
  • 1970-01-01
  • 2012-07-03
  • 2018-10-23
  • 2012-08-12
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多