【问题标题】:Is it possible to optimize a query that gets all the rows in a table是否可以优化获取表中所有行的查询
【发布时间】:2016-09-24 05:56:21
【问题描述】:

我有这个问题

SELECT id, alias, parent FROM `content`

有没有办法优化这个查询,所以 'type' 与 'all' 不同

id - 主要的,唯一的

id - 索引

父-索引

别名 - 索引

....

请注意,此查询几乎不会返回超过 1500 行。

谢谢

【问题讨论】:

  • 据我了解问题 - 否。但是在使用这个查询时可以进行优化:查询数据的下一个生命周期是什么?
  • 你可以通过删除一些行来优化它:p
  • Jacek - 不确定你的意思
  • Drew - 出于某种原因,它被慢速查询报告拾取,但它没有意义,因为每次我在 phpmyadmin 上运行它时都会得到 0.00XXs。可能这是用于开发的新服务器,因此数据偏斜
  • 甚至 MySQL 工作台限制为 1000 行。他们认为一个人真的不是要带回 3120 万行

标签: mysql optimization indexing


【解决方案1】:

您的查询正在获取所有行,因此根据定义,它将在 EXPLAIN 报告中报告“ALL”作为查询类型。唯一的另一种可能性是“索引”查询类型,一种访问索引中每个条目的索引扫描。但这实际上与表扫描的成本相同。

有一种说法,最快的 SQL 查询是您根本不运行的查询,因为您以其他方式获取数据。

例如,如果数据在某种类型的缓存中。如果您的数据不超过 1500 行,并且不经常更改,那么它可能是放入内存的好选择。然后只有在缓存数据丢失时才运行 SQL 查询。

有几个常见的选项:

  • MySQL query cache 是在 MySQL 服务器中维护的内存缓存,当表中的数据发生变化时会自动清除。

  • Memcached 是一种流行的内存键值存储,经常被同样使用 MySQL 的应用程序使用。它非常快。另一个选项是Redis,它与此类似,但也有磁盘存储支持。

【讨论】:

    【解决方案2】:

    OFFlog_queries_not_using_indexes;它使缓慢的原木变得混乱,就像你得到的那样。

    0.00XX 秒 -- 好到不用担心。

    ALL 实际上最适合从表的“所有”行中获取多列。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2010-11-14
      • 2021-11-11
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多