MySQL查询小于和ORDER BY DESC

Question

我正在处理大量数据，并试图从四个不同数据的每种组合中创建一个查询。 所有这些组合在一起形成了惊人的122,000,000行。 然后，我试图找到小于一定数量的权重，并按从最高到最低的另一个值进行排序。

我可以使用weight < x没问题。

我可以用weight < x order by height ASC没问题。

当x围绕上下两端时，我什至可以使用weight < x order by height DESC 。 但是一旦它开始蔓延到中间，它很快就会从几秒上升到几分钟，直到“我不会等那么久”。

有什么想法吗？ （名称已更改，但类型未更改）

创建：

CREATE TABLE combinations (
    id bigint(20) unsigned NOT NULL auto_increment,
    up smallint(2) NOT NULL,
    left smallint(2) NOT NULL,
    right smallint(2) NOT NULL,
    down smallint(2) NOT NULL,
    weight decimal(5,1) NOT NULL,
    width smallint(3) NOT NULL,
    forward decimal(6,2) NOT NULL,
    backwards decimal(5,2) NOT NULL,
    in decimal(7,2) NOT NULL,
    out smallint(3) NOT NULL,
    height smallint(3) NOT NULL,
    diameter decimal(7,2) NOT NULL,
    PRIMARY KEY  (id)
);

索引

ALTER TABLE combinations ADD INDEX weight_and_height(weight,height);

查询

SELECT * FROM combinations WHERE weight < 20 ORDER BY height DESC limit 0,5;

讲解

| id | select type | table        | type  | possible_keys     | key               | key_len | ref  | rows | extra       |
|  1 | simple      | combinations | index | weight_and_height | weight_and_height | 5       | NULL |   10 | using where |

Answer 1

您的索引仅用于过滤weight 。 步骤如下：

1. 所有与行weight < x WHERE ）被发现（使用开始与任何索引weight ）
2. 该集合已排序（ ORDER BY height ... ）
3. 跳过0（ OFFSET ）行；
4. 交付了5（ LIMIT ）行。

可能代价高昂的部分是步骤1。可能在您的示例中，“ 20”在列表中很早。 实际上， EXPLAIN估计该集合只有10行。 对于较大的x值，步骤1需要更长的时间。 那是不可避免的。

处理步骤1中的所有行； 因此，步骤2的时间也有所不同。 （5.6进行了额外的优化，部分结合了步骤2、3、4。）

您真的在执行SELECT *吗？ 例如，如果您只想使用SELECT id ，则INDEX(weight, height, id)运行速度会更快，因为可以在索引中完全执行查询。

如果确实需要您提到的查询，那么它将运行得更快：

SELECT c.*
    FROM (
        SELECT id FROM combinations
            WHERE weight < 20 ORDER BY height DESC limit 0,5
         ) ids
    JOIN combinations AS c  USING(id)
    ORDER BY height DESC;

笔记：

• 如前所述，子查询是“使用索引”。
• 子查询仅传递5行。
• 外部SELECT仅需要处理5行。
• id被索引（因为它是PRIMARY KEY ），所以JOIN是有效的。
• （回复：标题）“小于”和“ DESC”不重要。