经过我们服务的一些预期的增长后,所有突然的一些更新都花了很长时间,这些过去非常快,直到表达到大约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是主键,它在另一个字段上有一个唯一索引(未包含在更新中).
这是一张innodb表.
什么可能是原因的任何指针？
任何可以帮助追踪问题的特定变量？
更新有“解释”吗？
编辑：我也注意到该表还有一个：
`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)
最佳答案
原文链接：https://www.f2er.com/mysql/434135.html