首頁>Database>source

我試圖弄清楚為什麼用 LIMIT 1进行簡單選擇 子句(诚然,在具有很多行和索引的非常膨脹的表上)有時需要30秒钟以上(有時甚至是2分钟)才能在AwS RDS Aurora例項上執行.這是在作家例項上。

似乎是从客戶端进行的第一个查詢,仅在遍歷成千上万行的特定選擇上發生,並且有時是這樣。

查詢的格式為:

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; 試圖重現延迟,但没有成功.如果愿意的话,很乐意提供有關基础架構的更多資訊。

More info

SHOW VARIABLES LIKE 'query_cache%';
SHOW GLOBAL STATUS LIKE 'Qc%';

已檢查並發送的行(来自Performance Insights):

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
最新回復
  • 5月前
    1 #

    考虑建立此複合索引,

    CREATE INDEX some_table_indx_col3_col2 ON some_table(col3,col2);
    

    您應该删除col3索引,以避免索引冗餘並节省儲存空間。

    Considering these existing details, 
    Query_cache_size        2,556,593,152 
    less Qcache_free_memory 2,555,753,592 
                           ---------------- 
    Query_cache bytes in use      839,560 
    Qcache_queries_in_cache     /     288 
    You have avg bytes per query    2,915 in use 
    Consider query_cache_limit of 192K  for ~ 64 * avg bytes per query 
    query_cache_min_res_unit          512  the minimum to store more queries in your cache 
    query_cache_size   50M   for ~ 64 * Query_cache bytes in use - from ~2.5G size.
    

    要节省每次需要qcache_lowmem_prunes時使用的98%的CPU週期。

    如果在完成請求的表删除之前删除了与从innodb_buffer_pool更改活動进行重新整理有關的innodb表,則会观察到停顿。

    請让我们知道您的进度/挫败感,並考虑授予赏金。 新年快乐

  • sql server:試圖了解RCSI示例-讀取提交的快照隔离級別的潜在危险
  • mysql:MariaDB InnoDB不会在超時時迴滚