Question

在我们的服务有一些预期的增长后，所有突然的一些更新都花了很长时间，这些过去非常快，直到表达到大约2MM的记录，现在它们大约需要40-60秒。

update table1 set field1=field1+1 where id=2229230;
Query OK, 0 rows affected (42.31 sec)
Rows matched: 1  Changed: 0  Warnings: 0

以下是字段类型：

`id` bigint(20) NOT NULL auto_increment,
`field1` int(11) default '0',

分析的结果，对于上下文切换，这是唯一一个似乎在结果上有高数字的切换：

mysql> show profile context switches
    -> ;
+----------------------+-----------+-------------------+---------------------+
| Status               | Duration  | Context_voluntary | Context_involuntary |
+----------------------+-----------+-------------------+---------------------+
| (initialization)     | 0.000007  |                 0 |                   0 |
| checking permissions | 0.000009  |                 0 |                   0 |
| Opening tables       | 0.000045  |                 0 |                   0 |
| System lock          | 0.000009  |                 0 |                   0 |
| Table lock           | 0.000008  |                 0 |                   0 |
| init                 | 0.000056  |                 0 |                   0 |
| Updating             | 46.063662 |             75487 |               14658 |
| end                  | 2.803943  |              5851 |                 857 |
| query end            | 0.000054  |                 0 |                   0 |
| freeing items        | 0.000011  |                 0 |                   0 |
| closing tables       | 0.000008  |                 0 |                   0 |
| logging slow query   | 0.000265  |                 2 |                   1 |
+----------------------+-----------+-------------------+---------------------+
12 rows in set (0.00 sec)

该表大约有250万条记录，id是主键，它在另一个字段上有一个唯一索引（未包含在更新中）。

这是一个无与伦比的表格。

关于可能是什么原因的任何指示？

任何有助于追踪问题的特定变量？

是否有更新的“解释”？

编辑：我还注意到该表还有一个：

`modDate` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,

说明：

+----+-------------+---------------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table         | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+---------------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | table1        | const | PRIMARY       | PRIMARY | 8       | const |    1 |       |
+----+-------------+---------------+-------+---------------+---------+---------+-------+------+-------+
1 row in set (0.02 sec)

Answer 1

如果id确实是主键，那么查询应该花费很长时间（除非你有很多很多的id等于2229230？）。请运行以下两个sqls并发布结果：

show create table table1;
explain select * from table1 where id = 2229230;

更新：只是为了完成，也做一个

select count(*) from table1 where id = 2229230;

Answer 2

好几个小时追踪这个，看起来原因是一个“重复索引”，我正在回答Keith的创建表，有这个奇怪的组合：

fieldx上的唯一键
fieldx上的一个键

第二个显然是冗余和无用的，但在我放弃密钥后，所有更新都返回到＆lt; 1秒。

+1给Keith和Ivan，因为他们的评论帮助我最终找到了问题。

Answer 3

我也可以推荐一下：

OPTIMIZE TABLE table1;

有时你的桌子只需要一点点爱情，如果它们快速增长并且你没有在一段时间内优化它们，那么指数可能会有点疯狂。事实上，如果你有时间（而且你有），那么投入

永远不会受到伤害

REPAIR TABLE table1;

Answer 4

对我有帮助的是将引擎从'innodb'改为'myisam'。我对类似大小的数据集的更新查询从100毫秒到0.1毫秒。

请注意，更改现有应用程序的引擎类型可能会产生影响，因为InnoDB具有更好的数据完整性以及应用程序可能依赖的某些功能。

对我来说，值得丢失InnoDB，以便在大数据集上加速1000倍。

Answer 5

我遇到过同样的问题，原因是桌面上有触发因素。每次在我的表上进行更新时，触发器都会更新另一个表，这是实际造成的延迟。在该表上添加索引修复了该问题。因此，请尝试检查表格中的触发器。

Answer 6

与select语句版本相比，调试更新语句时需要考虑的另一件事是：是在事务中执行的更新语句吗？

在我的情况下，事务将更新语句从极快的执行时间转换为极慢的执行时间。行数越多，性能损失越重。我的陈述与用户定义的变量一起使用，但不知道问题的那一部分是不是

。

MySQL更新（太长时间）了

6 个答案: