我想知道为什么一个简单的选择 LIMIT 1 子句（不可否认，在一个包含大量行和索引的非常臃肿的表上）有时在awsrds aurora示例上执行需要30多秒（有时甚至2分钟）。这是一个writer示例。
对于来自客户机的第一个查询，它似乎只发生在查看成千上万行的特定select上，而且有时也会发生。
查询的格式为：

SELECT some_table.col1, some_table.col2, some_table.col3, some_table.col4, 
  MAX(some_table.col2) AS SomeValue 
FROM some_table 
WHERE some_table.col3=123456 LIMIT 1;

和“解释”输出：

+----+-------------+---------------+------+---------------+---------+---------+-------+--------+-------+
| id | select_type | table         | type | possible_keys | key     | key_len | ref   | rows   | Extra |
+----+-------------+---------------+------+---------------+---------+---------+-------+--------+-------+
|  1 | SIMPLE      | some_table    | ref  | col1          | col1    | 4       | const | 268202 | NULL  |
+----+-------------+---------------+------+---------------+---------+---------+-------+--------+-------+

我设法重现了这个问题，并在phpmyadmin中捕获了查询的概要文件。phpmyadmin记录查询的执行时间为30.1秒，但探查器显示执行本身的时间不到一秒：

所以看起来执行本身并不花费很多时间；是什么导致了这个延迟问题？我还发现了rds performance insights中记录的相同查询：

对于一系列相同或相似的查询中的第一个查询，似乎会发生这种情况。可能是缓存问题吗？我试过跑步 RESET QUERY CACHE; 试图重现潜伏期但没有成功。如果有帮助的话，我很乐意提供更多关于基础设施的信息。
更多信息

SHOW VARIABLES LIKE 'query_cache%';

SHOW GLOBAL STATUS LIKE 'Qc%';

检查并发送的行（来自性能分析）：
SHOW CREATE TABLE 输出：

CREATE TABLE `some_table` (
`col1` int(10) unsigned NOT NULL AUTO_INCREMENT,
`col2` int(10) unsigned NOT NULL DEFAULT '0',
`col3` int(10) unsigned NOT NULL DEFAULT '0',
`col4` int(10) unsigned NOT NULL DEFAULT '0',
`col5` mediumtext COLLATE utf8mb4_unicode_ci NOT NULL,
`col6` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
`col7` int(10) unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`col1`),
KEY `col2` (`col2`),
KEY `col3` (`col3`),
KEY `col4` (`col4`),
KEY `col6` (`col6`),
KEY `col7` (`col7`)
) ENGINE=InnoDB AUTO_INCREMENT=123456789 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci