为啥向这个 MySQL 查询添加特定的 where 子句会成为性能瓶颈？
Posted
技术标签:
【中文标题】为啥向这个 MySQL 查询添加特定的 where 子句会成为性能瓶颈？【英文标题】：Why is adding a specific where clause to this MySQL query a performance killing bottleneck?为什么向这个 MySQL 查询添加特定的 where 子句会成为性能瓶颈？ 【发布时间】：2012-04-09 01:19:22 【问题描述】：抱歉篇幅太长，想给出完整的描述！我需要显示一份报告，其中显示有关另一个表中的 id 的一些信息，以及当有人在 x 天内从一个国家/地区更改国家/地区时。请注意我如何可以在表中多次输入相同的国家/地区条目（因为信息会定期查询多次，但在此期间它们可能没有移动），并且还可以有不同的国家/地区条目（因为它们更改国家/地区）。
数据快速解释： 我有下表：
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 条记录但从未完成的国家/地区完成此查询花费了惊人的 6 分 54 秒（在下午和晚上外出之后
回家总共大约 8 小时）对于数据库中有 9000 条记录的国家/地区。在真实数据中，一个国家可能会轻松 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
所以它看起来更大，但并非不合理。
[删除了空间的配置变量，如果需要，请告诉我，还有性能信息，因为它可能是一个查询。]
如果我错过了什么，请告诉我。
【问题讨论】：
为什么WHERE子句中有ORDER BY？ @rontornambe 请注意最后的LIMIT 1。它返回满足内部 where 子句的最新时间戳
where 子句中的子查询为我提供了该 ID 的下一个最早时间戳事件。如果没有 order by 我可以得到任何更早的行，但是如果 order by timestamp desc 限制为一个，我只能得到之前的一个。
只是想知道 - ORDER BY 可能很昂贵。
请以以下形式向您的问题添加详细示例 - 鉴于此数据，我希望得到此结果。这将使您更容易准确地理解您想要实现的目标。
【参考方案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 位于外连接的外侧）的变化并非微不足道；处理查询条件需要更长的时间。
这是否意味着因为我不是在寻找特定的 ID，所以我运气不好？
对于给定的查询结构，答案似乎是“是”，但给定的查询结构可能，容我们说，是次优的。
您的“处理一个 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 包括timestamp 的列中可能有一个NULL，但是子查询被浪费了，因为除非值是非空的，否则条件不会得到满足，所以我们最终想知道'为什么是 OUTER join'？
当您添加修改后的条件时，您应该收到“不明确的列名”错误，因为该时间戳可能来自 a 或 c。此外，b.country = "whatever" 条件是另一个仅在 b 值不为空时才有意义的条件，因此，OUTER 连接是可疑的。
据我了解，country 表包含有关谁进入哪个国家以及何时进入的记录。另外，FWIW，我可以肯定的是，与user_info 表的连接是一个可以忽略不计的性能问题；问题完全在于对country 表的三个引用。
从一些澄清来看，您可以逐步构建查询，可能是这样的。
查找同一 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 表中没有记录id 在两个时间戳之间（但不包括）a.timestamp 和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 表示法不适合。它包括范围内的端点，但我们明确需要排除端点。
鉴于上面的国家条目列表，我们现在只需要选择那些......嗯，标准是什么？我想你可以选择，但结果可以很容易地与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）。但我认为获取相邻日期的复杂查询结构比原始代码更简洁，性能可能更好。请特别注意，它不使用任何外连接、（显式）排序或限制子句。这应该会有所帮助。
【讨论】：
这是有道理的，并且当我删除 id 和国家和时间戳时，我发现查询运行的时间并没有真正减少。这是否意味着因为我没有寻找特定的 id 我运气不好？ 抱歉耽搁了。经过大量测试，这要好 1000% 倍。在一些我不完全确定的情况下，它仍然挂起。我认为在某些情况下，其中一个子查询可能会返回大量结果，这会减慢速度。谢谢 发现现在速度变慢的原因是，如果微型实例执行任何密集工作，AWS 会将它们限制为 1% cpu。这导致任何查询都经过一定数量的工作而几乎永远无法完成。我在一个小实例上再次尝试了您的查询，它在 40 秒内完成了 450 万行选择一个有 800,000 个条目的国家/地区。 这比您之前的性能要好很多。谢谢你的信息。【参考方案2】：你应该检查这个参考：http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_now
和http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_date-add
它说的是，NOW() 函数可以返回一个字符串（取决于上下文），而 date_add 可以返回一个字符串（取决于参数）。我的猜测是，您正在获取字符串，然后仅在比较时转换为日期（这发生在每条记录上）。您可以尝试 AND 时间戳 > cast(DATE_SUB(NOW(), INTERVAL 7 DAY) as datetime)，这可能会提高性能。
【讨论】：
这似乎没有多大帮助，因为即使我把它拿出来我也能得到类似的性能。【参考方案3】：我不建议将此作为一个完成的解决方案，但这是我将回到的开始。请让我知道这对您的测试数据集的执行情况 -
SELECT ui.*, c1.*, MAX(c2.timestamp)
FROM country c1
INNER JOIN user_info ui
ON c1.id = ui.id
INNER JOIN country c2
ON c1.id = c2.id
AND c1.timestamp > c2.timestamp
AND c1.country <> c2.country
WHERE c2.timestamp > DATE_SUB(NOW(), INTERVAL 7 DAY)
AND c2.country = 'somewhere'
GROUP BY c1.id
下一步是添加 LEFT JOIN 以确保中间没有其他记录 -
SELECT ui.*, c1.*, c2.timestamp
FROM country c1
INNER JOIN user_info ui
ON c1.id = ui.id
INNER JOIN country c2
ON c1.id = c2.id
AND c1.timestamp > c2.timestamp
AND c1.country <> c2.country
LEFT JOIN country c3
ON c1.id = c3.id
AND c1.timetsamp > c3.timestamp
AND c2.timestamp < c2.timetsamp
WHERE c2.timestamp > DATE_SUB(NOW(), INTERVAL 7 DAY)
AND c2.country = 'somewhere'
AND c3.id IS NULL
【讨论】：
我跑了它，至少它很快:) 我看到的问题：每个 id 仅 1 个（有人可以多次离开一个国家），仅显示他们第一次出现在旧国家，只有最后一次出现在旧国家。我会在 OP 中详细说明。 我增强了示例以显示我如何期望相同国家 ID 的倍数以及我期望它们的时间戳。每次他离开该国不止一次时，我可能不需要相同的身份证件出现。假设这会使查询更快，那么最新的就可以了。以上是关于为啥向这个 MySQL 查询添加特定的 where 子句会成为性能瓶颈？的主要内容，如果未能解决你的问题，请参考以下文章
如何编写一个同时适用于 HSQLDB 和 MySQL 的查询以在 WHERE 子句中为日期添加天数？
MySQL - SELECT WHERE field IN（子查询） - 为啥非常慢？
为啥对三个表的联合 mysql 查询比在不可能的 where 子句上连接更快？