我正在检查MySQL的慢查询日志,并找到了如下条目:
# Time: 131108 4:16:34
# Query_time: 14.726425 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 1
SET timestamp=1383884194;
UPDATE `Artist` SET ImageFilename = NULL, Title = 'Elton John', PopularityRating = 657, UniqueID = NULL, Description = NULL, IsFeatured = 0, FeaturedText = '', MetaDescription = '', MetaTitle = NULL, _Temporary_LastUpdOn = '2013-11-08 04:15:58 ', _Temporary_Flag = 0, _Deleted = 0, _DeletedOn = NULL, Priority = 0 WHERE ID = 3449748;
正如您所看到的,执行此查询时需要花费14.72秒的惊人时间,这是一个简单的更新,主键只有WHERE
。我已经尝试重新执行查询,但现在它在0.095秒内执行,这更合理。
我有什么想法可以调试为什么在这个特定的时间花了这么长时间?
编辑1:query_cache%变量
mysql> SHOW variables where variable_name like 'query_cache%';
+------------------------------+-----------+
| Variable_name | Value |
+------------------------------+-----------+
| query_cache_limit | 1048576 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 210763776 |
| query_cache_type | ON |
| query_cache_wlock_invalidate | OFF |
+------------------------------+-----------+
编辑2:艺术家表格信息
CREATE TABLE `artist` (
`ID` bigint(20) NOT NULL,
`ImageFilename` mediumtext,
`Title` varchar(1000) DEFAULT NULL,
`PopularityRating` int(11) DEFAULT '0',
`UniqueID` mediumtext,
`Description` mediumtext,
`IsFeatured` tinyint(1) DEFAULT '0',
`FeaturedText` mediumtext,
`_Temporary_LastUpdOn` datetime DEFAULT '0001-01-01 00:00:00',
`_Temporary_Flag` tinyint(1) DEFAULT '0',
`_Deleted` tinyint(1) DEFAULT '0',
`_DeletedOn` datetime DEFAULT NULL,
`Priority` int(11) DEFAULT '0',
`MetaDescription` varchar(2000) DEFAULT NULL,
`MetaTitle` mediumtext,
PRIMARY KEY (`ID`),
KEY `_Temporary_Flag` (`_Temporary_Flag`),
KEY `_Deleted` (`_Deleted`),
KEY `Priority` (`Priority`),
KEY `PopularityRating` (`PopularityRating`),
KEY `Title` (`Title`(255)),
KEY `IsFeatured` (`IsFeatured`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
答案 0 :(得分:1)
根据您提供的输出,我的建议是最小化您的缓存大小。它只是我最好的假设,这导致更新时间超过15秒,因为使用WHERE
上的PRIMARY KEY
查询本身是最佳的。
由于你无法重现问题,很难确定。
我正在再次阅读缓存文档以获取一些信息。
修改表时,将刷新查询缓存中的所有相关条目。 这可能是您所做的更新必须刷新缓存数据的原因。
文件的另一部分
小心调整查询缓存的大小,这个问题 增加维护缓存所需的开销,可能超出 启用它的好处。通常是几十兆字节的大小 有利。数百兆字节的大小可能不是。
无论哪种方式,由于您启用了查询缓存,我认为这是一个很好的起点。
在生产中设置新的查询缓存
SET GLOBAL query_cache_size = 1000000;
Mysql会自动将大小设置为与最近的1024字节块对齐。
请仔细阅读本文档,这对理解非常有帮助。查询缓存可以同时是您最好的和最糟糕的设置。
答案 1 :(得分:0)
你的桌子有问题。您为表创建了多个索引,其中包括您将在sql中更新的字段。然后mysql每次都要重建索引。
答案 2 :(得分:0)
万一有人错过上面的评论:
也许那个时候桌子被锁住了。
由于您无法重现该问题,因此很可能是这种情况。