【问题标题】:Using filesort to order by price column in MySQL在 MySQL 中使用 filesort 按价格列排序
【发布时间】:2017-09-08 12:57:24
【问题描述】:

我有一个比这个更复杂的查询(获得最便宜的价格),但这代表性能问题很好。所以查询不能改变。

我尝试创建不同的索引来加快订购速度。

需要什么索引才能更快地获得这个 1.4 秒的持续查询?如果我删除 ORDER BY 查询持续 0.05 秒,但我需要排序。

查询

SELECT id AS pid                    
  FROM prices pt                    
  WHERE pt.id = (    
      SELECT pt2.id                        
      FROM prices pt2                          
      WHERE pt2.oid=pt.oid                         
      ORDER BY pt2.price                           
      LIMIT 1
    )

解释

1   PRIMARY pt  index   NULL    id_price    12  NULL    9144    Using where; Using index
2   DEPENDENT SUBQUERY  pt2 ref oid,oid_price   oid 4   oid 23  Using where; Using filesort

索引

PRIMARY     PRIMARY 9144    id
price       INDEX   703     price
oid         INDEX   397     oid
id_price    INDEX   9144    id,price,oid
oid_price   INDEX   4572    oid,price

【问题讨论】:

标签: mysql performance indexing filesort


【解决方案1】:

查询不能更改的情况非常罕见;没有看过原著,很难确定。例如,您似乎正在尝试获取 id 列表,其中这些 id 是其“oid”的最低价格。

您作为示例给出的查询可以很容易地重写为不需要相关子查询;相关子查询通常是性能问题的根源。

SELECT p.id 
FROM (SELECT oid, MIN(price) AS minPrice FROM prices GROUP BY oid) AS mins
INNER JOIN prices AS p ON mins.oid = p.oid AND mins.minPrice = p.price
;

(oid, price) 上的索引可能是使上述查询快速所需的全部内容。

注意:结果的唯一区别应该是,如果有多个最低价格的条目,则该结果可以返回多个 id 值以获得相同的 oid 值;而不是有效地随机选择价格最低的id 值之一。

【讨论】:

  • 就像我说的,查询不能改变。每个 oid 有多种价格,也有不同的类型。此外,您的查询输出与上述结果不同的结果。我将问题归结为速度问题。
  • 问题是速度问题的根源可能是由于实际查询中固有的问题。如果“比这个复杂一点” 涉及在字段值上使用函数的条件,那么再多的索引也无济于事。 ...并且 “不同类型的” 没有反映在您提供的示例中,那么任何答案如何解释呢?
  • 没有。我将问题简化为上面的查询,就像我说的那样非常慢。因此,如果这可以通过巧妙的索引来加快速度,那么原始查询也会更好地工作。
  • oid_price 索引应该是所有查询需要的;问题是 correlated subquery 会为prices 中的每一行单独调用。
  • 您提出的查询对我不起作用。还有其他想法吗?
猜你喜欢
  • 2010-12-01
  • 2021-02-12
  • 2014-02-17
  • 2021-11-12
  • 2023-03-31
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多