mysql - 为什么向此 MySQL 查询添加特定的 where 子句会成为性能瓶颈？

Question

抱歉篇幅太长，想给出一个完整的描述!我需要显示一份报告，显示有关另一个表中的 id 的一些信息，以及当有人在 x 天内从一个国家/地区更改国家/地区时。请注意，我如何可以在表中多次为一个 ID 使用相同的国家/地区条目(因为信息会定期多次查询，但在那段时间它们可能没有移动)，并且还可以有不同的国家/地区条目(因为它们更改国家/地区)。

数据的快速解释:我有下表:

CREATE TABLE IF NOT EXISTS `country` (
`id` mediumint(8) unsigned NOT NULL,
`timestamp` datetime NOT NULL,
`country` varchar(64) DEFAULT NULL,
PRIMARY KEY (`id`,`timestamp`),
KEY `country` (`country`),
KEY `timestamp` (`timestamp`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

条目是这样的:

41352   2012-03-26 15:46:01     Jamaica
41352   2012-03-05 22:49:41     Jamaican Applicant
41352   2012-02-26 15:46:01     Jamaica
41352   2012-02-16 12:11:19     Jamaica
41352   2012-02-05 23:00:30     Jamaican Applicant

该表目前总共约有 214,590 行，但一旦测试数据被替换为真实数据，将会有数百万行。

我想要的是关于自 y 时间以来离开 x 国家/地区的每个人的一些信息。假设它是在上面的数据上运行的，我希望它的输出方式如下:

id  name    last    country     TIMESTAMP   o_timestamp
41352 Sweet Mercy   Jamaica     2012-03-26 15:46:01     2012-03-05 22:49:41
41352 Sweet Mercy   Jamaica     2012-02-16 12:11:19     2012-02-05 23:00:30

o_timestamp 比某个日期(比如说 100)更新的地方，国家是他们搬到的地方，他们来自的旧国家(未显示)是我传递给查询的任何内容(牙买加申请人基于上述数据) .

为了满足需求，我开发了以下查询，并使用某个id进行测试:

SELECT a.id,
       c.name,
       c.last,
       a.country,
       a.timestamp,
       b.timestamp AS o_timestamp
FROM   country a
       INNER JOIN user_info c
         ON ( a.id = c.id )
       LEFT JOIN country AS b
         ON ( a.id = b.id
              AND a.timestamp != b.timestamp
              AND a.country != b.country )
WHERE  b.timestamp = (SELECT c.timestamp
                      FROM   country c
                      WHERE  a.id = c.id
                             AND a.timestamp > c.timestamp
                      ORDER  BY c.timestamp DESC
                      LIMIT  1) 
       AND a.id = 965

我完成了这个(总共 7 次，查询用了 0.0050 秒)

扩展解释揭示了以下内容:

id  select_type     table   type    possible_keys   key     key_len     ref     rows    filtered    Extra
1   PRIMARY     c   const   PRIMARY     PRIMARY     3   const   1   100.00  
1   PRIMARY     a   ref     PRIMARY     PRIMARY     3   const   16  100.00  
1   PRIMARY     b   eq_ref  PRIMARY,timestamp   PRIMARY     11  const,func  1   100.00  Using where
2   DEPENDENT SUBQUERY  c   index   PRIMARY,timestamp   timestamp   8   NULL    1   700.00  Using where; Using index

所以我觉得我很不错，于是就加入了这个:

SELECT a.id,
       c.name,
       c.last,
       a.country,
       a.timestamp,
       b.timestamp AS o_timestamp
FROM   country a
       INNER JOIN user_info c
         ON ( a.id = c.id )
       LEFT JOIN country AS b
         ON ( a.id = b.id
              AND a.timestamp != b.timestamp
              AND a.country != b.country )
WHERE  b.timestamp = (SELECT c.timestamp
                      FROM   country c
                      WHERE  a.id = c.id
                             AND a.timestamp > c.timestamp
                      ORDER  BY c.timestamp DESC
                      LIMIT  1) 
       AND b.country = "whatever" AND timestamp > DATE_SUB(NOW(), INTERVAL 7 DAY)

在一个拥有 200 条记录且从未完成的国家/地区(在下午和晚上外出和

对于一个在数据库中有 9000 条记录的国家/地区，总共需要大约 8 个小时才能回家。在真实数据中，一个国家可能在那里容易 10000 倍。 100k 不会不合理。

所以我确实解释了扩展，并得到了这个:

id  select_type     table   type    possible_keys   key     key_len     ref     rows    filtered    Extra
1   PRIMARY     <derived2>  ALL     NULL    NULL    NULL    NULL    3003    100.00  
1   PRIMARY     c   eq_ref  PRIMARY     PRIMARY     3   b.id    1   100.00  
1   PRIMARY     a   ref     PRIMARY     PRIMARY     3   b.id    7   100.00  Using where
3   DEPENDENT SUBQUERY  c   index   PRIMARY,timestamp   timestamp   8   NULL    1   700.00  Using where; Using index
2   DERIVED     country     range   country,timestamp   country     195     NULL    474     100.00  Using where; Using index

所以它看起来更大，但并非没有道理。

[删除了空间的配置变量，如果需要请告诉我，还有性能信息，因为它可能是一个查询问题。]

如果我遗漏了什么，请告诉我。

Answer 1

问题不在于添加标准；它正在掉落一个造成伤害的东西。在原始查询中，您有:

AND a.id = 965

这意味着查询执行不需要读取整个a (country) 表。在您的第二个性能下降的查询中，您将该标准更改为:

AND b.country = "whatever"
AND timestamp > DATE_SUB(NOW(), INTERVAL 7 DAY)

您不再对 a 有真正的限制性标准，因此工作速度要慢得多。

当意识到 b 是对 country 的另一个引用时，事情变得更加复杂。然而，从 a 到 b 的条件(其中 b 位于外部连接的外侧)的变化并非微不足道；处理查询条件需要更长的时间。

---

Does that mean because I'm not looking for a specific id, I'm out of luck?

对于给定的查询结构，答案似乎是"is"，但我们可以说，给定的查询结构可能是次优的。

您的“处理一个 ID 时足够快”查询是:

SELECT a.id,
       c.name,
       c.last,
       a.country,
       a.timestamp,
       b.timestamp AS o_timestamp
FROM   country a
       INNER JOIN user_info c
         ON ( a.id = c.id )
       LEFT JOIN country AS b
         ON ( a.id = b.id
              AND a.timestamp != b.timestamp
              AND a.country != b.country )
WHERE  b.timestamp = (SELECT c.timestamp
                      FROM   country c
                      WHERE  a.id = c.id
                             AND a.timestamp > c.timestamp
                      ORDER  BY c.timestamp DESC
                      LIMIT  1) 
       AND a.id = 965

我不完全理解这个查询以及它试图做什么。您需要注意外连接比内连接更昂贵，并且外连接表上的条件如

b.timestamp = (...correlated sub-query...)

非常昂贵。一个问题是 b 列中可能有一个 NULL，包括 timestamp，但是子查询被浪费了，因为除非值是非空的，所以我们最终想知道“为什么要进行 OUTER 连接”？

当您添加修改后的条件时，您应该收到“列名不明确”错误，因为该时间戳可能来自 a 或 c。此外，b.country = "whatever" 条件是另一个只有当 b 值不为 null 时才有意义的条件，因此 OUTER 连接也是可疑的。

据我了解，country 表包含有关谁进入哪个国家以及何时的记录。此外，FWIW，我可以肯定的是，与 user_info 表的连接是一个可以忽略不计的性能问题；问题全在于对 country 表的三个引用。

---

从一些说明来看，您可以逐步构建查询，也许是这样的。

1. 查找同一 id 的每对国家记录，其中记录在时间顺序上相邻，并且较早的记录对应给定国家(“牙买加申请人”)和较新的适用于不同的国家/地区。

   最简单的部分是:

   SELECT a.id, a.country, a.timestamp, b.country, b.timestamp
     FROM country AS a
     JOIN country AS b
       ON a.id = b.id
      AND b.timestamp > a.timestamp
      AND a.country = 'Jamaica Applicant'
      AND b.country != a.country
   

   这完成了大部分工作，但不能确保条目的邻接性。为此，我们必须坚持在 country 表中没有记录在两个时间戳 a 之间(但不包括)相同的 id。时间戳 和b.timestamp。这是一个额外的 NOT EXISTS 条件:

   SELECT a.id,
          a.country   AS o_country,
          a.timestamp AS o_timestamp,
          b.country   AS n_country,
          b.timestamp AS n_timestamp
     FROM country AS a
     JOIN country AS b
       ON a.id = b.id
      AND b.timestamp > a.timestamp
      AND a.country = 'Jamaica Applicant'
      AND b.country != a.country
    WHERE NOT EXISTS
          (SELECT *
             FROM country AS c
            WHERE c.timestamp > a.timestamp
              AND c.timestamp < b.timestamp
              AND c.id = a.id
          )
   

   请注意，BETWEEN AND 符号不适用。它包括范围内的端点，但我们明确需要排除端点。

2. 鉴于上面的国家/地区条目列表，我们现在只需要选择那些...嗯，那么，标准是什么？我想你可以选择，但结果可以很容易地与 user_info 表连接:

   SELECT e.id, u.name, u.last, e.o_country, e.o_timestamp, e.n_country, e_n_timestamp
     FROM (SELECT a.id,
                  a.country   AS o_country,
                  a.timestamp AS o_timestamp,
                  b.country   AS n_country,
                  b.timestamp AS n_timestamp
             FROM country AS a
             JOIN country AS b
               ON a.id = b.id
              AND b.timestamp > a.timestamp
              AND a.country = 'Jamaica Applicant'
              AND b.country != a.country
            WHERE NOT EXISTS
                  (SELECT *
                     FROM country AS c
                    WHERE c.timestamp > a.timestamp
                      AND c.timestamp < b.timestamp
                      AND c.id = a.id
                  )
          ) AS e
     JOIN user_info AS u ON e.id = u.id
    WHERE e.o_timestamp > DATE_SUB(NOW(), INTERVAL 7 DAY);
   

我不保证性能会更好(甚至它在语法上是正确的；它还没有通过 SQL DBMS)。但我认为用于获取相邻日期的复杂查询结构比原始代码更简洁并且性能可能更好。请特别注意，它不使用任何外部连接、(显式)排序或限制子句。这应该有所帮助。