【问题标题】:occasional slow UPDATE using primary key使用主键偶尔缓慢更新
【发布时间】:2017-10-29 21:07:46
【问题描述】:

我在 MySQL 5.5.53 中有一个 InnoDB 表,其中进行了简单的更新,例如

UPDATE mytable SET acol = 'value' WHERE id = 42;

暂停几秒钟。 id 是表的主键。

如果我启用查询分析使用

SET profiling = 1;

然后运行查询并查看配置文件,我看到如下内容:

show profile;
+------------------------------+----------+
| Status                       | Duration |
+------------------------------+----------+
| starting                     | 0.000077 |
| checking permissions         | 0.000008 |
| Opening tables               | 0.000024 |
| System lock                  | 0.000008 |
| init                         | 0.000346 |
| Updating                     | 0.000108 |
| end                          | 0.000004 |
| Waiting for query cache lock | 0.000002 |
| end                          | 3.616845 |
| query end                    | 0.000016 |
| closing tables               | 0.000015 |
| freeing items                | 0.000023 |
| logging slow query           | 0.000003 |
| logging slow query           | 0.000048 |
| cleaning up                  | 0.000004 |
+------------------------------+----------+

也就是说,所有的时间都花在end上。

The documentation 说:

  • end

    这发生在最后,但在清理 ALTER TABLECREATE VIEWDELETEINSERTSELECTUPDATE 语句之前。

这么简单的语句怎么会在这种状态下花费这么长时间?

【问题讨论】:

  • 我很想知道这张表中有多少行。并且您在使用此表的应用程序中是否有更多更新/插入/删除或更多选择?
  • 300000行左右,不知道读写比例。

标签: mysql query-cache


【解决方案1】:

原来问题出在查询缓存上。

如果我禁用它

SET GLOBAL query_cache_size = 0;
SET GLOBAL query_cache_type = 0;

问题消失了。

一定是使查询缓存条目无效导致查询挂起这么长时间。

【讨论】:

    猜你喜欢
    • 2013-04-14
    • 1970-01-01
    • 1970-01-01
    • 2013-04-03
    • 2015-07-22
    • 2015-05-17
    • 2010-09-08
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多