SQL 在使用 ORDER BY 的简单查询时变慢答案

【问题标题】：SQL gets slow on a simple query with ORDER BYSQL 在使用 ORDER BY 的简单查询时变慢
【发布时间】：2021-02-17 11:25:55
【问题描述】：

我在使用 MySQL ORDER BY 时遇到问题，它会减慢查询速度，我真的不知道为什么，我的查询有点复杂，所以我将其简化为没有连接的轻量查询，但它的运行速度仍然很慢.

查询：

SELECT
    W.`oid`
FROM
    `z_web_dok` AS W
WHERE
    W.`sent_eRacun` = 1 AND W.`status` IN(8, 9) AND W.`Drzava` = 'BiH'
ORDER BY W.`oid` ASC 
LIMIT 0, 10

表格有946,566行，内存占用500 MB，我选择的那些字段都索引如下：

oid - INT PRIMARY KEY AUTOINCREMENT
status - INT INDEXED
sent_eRacun - TINYINT INDEXED
Drzava - VARCHAR(3) INDEXED

我首先发布解释查询的屏幕截图：

接下来是对数据库执行的查询：

这是我删除 ORDER BY 后的速度。

我也尝试使用也被索引的 DATETIME 字段进行排序，但我得到的查询与使用主键排序一样慢，从今天开始，通常它总是快速而轻便。什么会导致这种情况？

【问题讨论】：

标签： mysql performance query-optimization mysql-slow-query-log

【解决方案1】：

您在此处使用的查询类型需要复合 covering index。这个应该可以很好地处理您的查询。

CREATE INDEX someName ON z_web_dok (Drzava, sent_eRacun, status, oid);

为什么会这样？您正在寻找前三列的相等匹配，并在第四列进行排序。查询计划器将使用此索引来满足整个查询。它可以随机访问索引以找到与您的查询匹配的第一行，然后扫描索引以获得所需的行。

专业提示：单个列上的索引通常会损害性能，除非它们恰好符合应用程序中特定查询的要求，或者用于主键或外键。您通常会选择索引来匹配最活跃或最慢的查询。编辑您询问为应用程序中的每个查询创建特定索引是否更好。答案是是的。

【讨论】：

感谢您的提示，我将尝试这种方式。但是有了这种想法，最好为每个不同的搜索创建不同的索引组而不是同一张表上的单个索引？
我已经在 z_web_dok (Drzava, sent_eRacun, status, dat_zavrsena) 上创建了 CREATE INDEX eracunindex 并且查询在 0.0007 秒内运行，谢谢，我正在考虑重新索引我的整个表..
轰隆隆！ 3.3 秒到 700 微秒。 请查看我的编辑。请查看use-the-index-luke.com 了解有效索引。
添加到最后的“是”：一旦为每个 SELECT 设计了最佳索引，就可以摆脱重复和重叠索引。具体来说：当你有INDEX(a,b)时，你不需要INDEX(a)。但是INDEX(b)不能被它淘汰。
谨慎——如果您有一个每月任务是查询的唯一用户，则可能建议将其删除。

【解决方案2】：

可能还有更快的方法。（或者它可能不会更快。）

IN(8, 9) 妨碍了完全有效地轻松处理WHERE..ORDER BY..LIMIT。可能的解决方案是将其视为OR，然后转换为UNION 并使用LIMIT 做一些技巧，特别是如果您还可能使用OFFSET。

( SELECT ... WHERE .. = 8 AND ... ORDER BY oid LIMIT 10 )
UNION ALL
( SELECT ... WHERE .. = 9 AND ... ORDER BY oid LIMIT 10 )
ORDER BY oid LIMIT 10

这将允许 OJones 描述的覆盖索引在每个子查询中得到充分使用。此外，每个将提供最多 10 行任何临时表或文件排序。然后外部部分将排序多达 20 行并提供“正确”的 10。

对于OFFSET，请参阅http://mysql.rjweb.org/doc.php/index_cookbook_mysql#or

【讨论】：