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

标签 mysql performance

我在查看MySQL的slow-query-log,发现了如下条目:

# 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

最佳答案

鉴于您提供的输出,我的建议是尽量减少缓存大小。这当然只是我最好的假设,这导致更新时间超过 15 秒,因为在 PRIMARY KEY 上使用 WHERE 查询本身是最佳的。

由于您无法重现问题,因此很难确定。

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

When tables are modified, any relevant entries in the query cache are flushed. This could be a reason for the update you did that it had to flush cached data.

文档的另一部分

Be cautious about sizing the query cache excessively large, which increases the overhead required to maintain the cache, possibly beyond the benefit of enabling it. Sizes in tens of megabytes are usually beneficial. Sizes in the hundreds of megabytes might not be.

无论哪种方式,既然您启用了查询缓存,我认为这是一个很好的起点。

在生产环境中设置新的查询缓存

SET GLOBAL query_cache_size = 1000000;

Mysql 会自动设置大小对齐到最近的 1024 字节 block 。

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

http://dev.mysql.com/doc/refman/5.1/en/query-cache.html

关于mysql - 简单的更新查询需要很长时间才能在 MySQL 中执行,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19854673/

相关文章:

MYSQL 需要 group by 但查询会产生错误的结果

mysql - 触发错误

performance - Web 应用程序性能基准的建议

mysql - 与其他实体有随机关系的实体

c# - 为什么我的正则表达式的编译速度比解释速度慢得多?

mysql - 仅在行首查找和替换

php - 检查 MySQL 数据库 PHP 中的现有 URL

php - 使用php删除图像文件

performance - Couchbase查询执行时间?

python - Python中len()和pop()的效率