gpt4 book ai didi

MySQL 慢查询 - "Waiting for query cache lock"

转载 作者:IT老高 更新时间:2023-10-28 23:49:57 25 4
gpt4 key购买 nike

我正在与运行 5.5 的服务器在同一台机器上的一个简单表上运行一个简单查询。从 2000 万行表中返回约 7000 行需要 22 秒。在进行分析时,大部分时间都被多个“等待查询缓存锁定”占用。什么是“等待查询缓存锁定”,为什么这个查询需要这么长时间?与我设置服务器的方式有关吗?

这是配置文件(注意操作的时间实际上来自下面的行,如 here 所述):

mysql> show profile for query 4;
+--------------------------------+----------+
| Status | Duration |
+--------------------------------+----------+
| starting | 0.000015 |
| Waiting for query cache lock | 0.000003 |
| checking query cache for query | 0.000045 |
| checking permissions | 0.000006 |
| Opening tables | 0.000027 |
| System lock | 0.000007 |
| Waiting for query cache lock | 0.000032 |
| init | 0.000018 |
| optimizing | 0.000008 |
| statistics | 0.033109 |
| preparing | 0.000019 |
| executing | 0.000002 |
| Sending data | 4.575480 |
| Waiting for query cache lock | 0.000005 |
| Sending data | 5.527728 |
| Waiting for query cache lock | 0.000005 |
| Sending data | 5.743041 |
| Waiting for query cache lock | 0.000004 |
| Sending data | 6.191706 |
| end | 0.000007 |
| query end | 0.000005 |
| closing tables | 0.000028 |
| freeing items | 0.000008 |
| Waiting for query cache lock | 0.000002 |
| freeing items | 0.000182 |
| Waiting for query cache lock | 0.000002 |
| freeing items | 0.000002 |
| storing result in query cache | 0.000004 |
| logging slow query | 0.000001 |
| logging slow query | 0.000002 |
| cleaning up | 0.000003 |
+--------------------------------+----------+

这是表格:

mysql> SHOW CREATE TABLE prvol;

"Table","Create Table"
"prvol","CREATE TABLE `prvol` (
`ticker` varchar(10) DEFAULT NULL,
`date` date DEFAULT NULL,
`close` float unsigned DEFAULT NULL,
KEY `Index 1` (`date`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1"

这里是查询:

mysql> select close from prvol where date = '20100203';

编辑: 使用 SQL_NO_CACHE 运行后,现在所有时间都在执行中。这对于在 2.4GHz、3GB 内存机器上的这种大小的表来说是正常的吗?

+----------------------+-----------+
| Status | Duration |
+----------------------+-----------+
| starting | 0.000052 |
| checking permissions | 0.000007 |
| Opening tables | 0.000027 |
| System lock | 0.000008 |
| init | 0.000019 |
| optimizing | 0.000008 |
| statistics | 0.034766 |
| preparing | 0.000011 |
| executing | 0.000002 |
| Sending data | 22.071324 |
| end | 0.000012 |
| query end | 0.000005 |
| closing tables | 0.000020 |
| freeing items | 0.000170 |
| logging slow query | 0.000001 |
| logging slow query | 0.000003 |
| cleaning up | 0.000004 |
+----------------------+-----------+

编辑:包括解释结果。

mysql> explain extended select cp from prvol where date = '20100208';
+----+-------------+-------+------+---------------+---------+---------+-------+------+----------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref |rows | filtered | Extra |
+----+-------------+-------+------+---------------+---------+---------+-------+------+----------+-------------+
| 1 | SIMPLE | prvol | ref | Index 1 | Index 1 | 4 | const |6868 | 100.00 | Using where |
+----+-------------+-------+------+---------------+---------+---------+-------+------+----------+-------------+
1 row in set, 1 warning (0.08 sec)

最佳答案

我解决了查询速度慢的问题。总结一下这个问题,从一个 2000 万行、1.7GB 的索引表中查询 7000 行需要 22 秒。问题是缓存太小,每次查询都必须转到磁盘。我认为磁盘访问会比我看到的更快,因为我正在使用索引列,所以从磁盘读取的数据量应该很小。但我猜想访问磁盘上的 InnoDB 存储会产生很多开销。

一旦我在 my.ini 文件中设置了 innodb_buffer_pool_size=1024M,初始查询将花费很长时间,但所有后续查询将在一秒钟内完成。

不幸的是,分析并没有真正帮助。

关于MySQL 慢查询 - "Waiting for query cache lock",我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5356975/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com