在MySQL中执行简单的更新查询需要很长时间

我在查看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:查询缓存%变量

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

---

考虑到您提供的输出，我的建议是最小化缓存大小。当然，这只是我最好的假设，这导致更新时间超过15秒，因为使用

主键
上的
WHERE
查询本身是最佳的

因为你还没能重现这个问题，所以很难确定

我再次阅读缓存文档以获取一些信息

修改表时，将刷新查询缓存中的所有相关条目。
这可能是您所做的更新必须刷新缓存数据的原因

文件的另一部分

在调整查询缓存的大小时要谨慎，否则会导致
增加维护缓存所需的开销，可能超过
启用它的好处。以数十兆字节为单位的大小通常是
有益的数百兆字节的大小可能不正确

无论哪种方式，由于您启用了查询缓存，我认为这是一个很好的起点

在生产中设置新查询缓存的步骤

SET GLOBAL query_cache_size = 1000000;

Mysql将自动将大小设置为与最近的1024字节块对齐

好好阅读这篇文档，这对理解很有帮助。查询缓存可以同时是您的最佳设置和最差设置

您的桌子有问题。您为该表创建了多个索引，其中包括将在sql中更新的字段。然后mysql每次都必须重建索引
 我认为您没有优化MySQL服务器变量，优化服务器变量以提高性能很重要。建议查看键缓冲区大小和表缓存变量

key_buffer_size变量控制MySQL索引缓冲区的可用内存量。该值越高，索引可用内存越多，性能越好

table_cache变量控制表缓存的可用内存量，从而控制MySQL在任何给定时间可以保持打开的表的总数。对于有许多数据库和表的繁忙服务器，应增加此值，以便MySQL能够可靠地为所有请求提供服务。
如果有人遗漏了上述注释：

也许那次桌子是锁着的

由于无法重现问题，可能是这种情况。
可能当时表被锁定。是否启用了缓存？可能有些牵强，但如果查询更改了缓存结果，则可能会出现性能下降。@Kaynlson我如何知道是否启用了缓存？@KarlCassar执行此命令可显示变量名称（如“query\u cache%”）；您可以发布
SHOW CREATE TABLE Artist
的输出吗？