MySQL中PK和另一个字段的表更新速度偶尔较慢

这是一个有趣的例子，MySQL中的更新有时会很慢。背景：48GB Innodb缓存，512MB ib日志。Innodb表，包含40mln行。结构和索引：

CREATE TABLE `VisitorCompetition` (
  `VisitorCompetitionId` bigint(20) NOT NULL AUTO_INCREMENT,
  `UserId` bigint(20) NOT NULL,
  `CompetitionInstanceId` bigint(20) NOT NULL,
  `Score` bigint(20) NOT NULL DEFAULT '0',
  `Visits` bigint(20) DEFAULT NULL,
  `Status` varchar(255) NOT NULL,
  `RankAtCompletion` int(11) DEFAULT NULL,
  `SessionId` varchar(36) DEFAULT NULL,
  `SharedDate` timestamp NULL DEFAULT NULL,
  `CreatedDate` timestamp(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
  `LastModifiedDate` timestamp(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
  `ModifiedBy` varchar(55) DEFAULT NULL,
  `CaseId` int(11) NOT NULL,
  PRIMARY KEY (`VisitorCompetitionId`),
  UNIQUE KEY `uc_UserId_CompetitionInstanceId` (`UserId`,`CompetitionInstanceId`),
  KEY `idx_VisitorCompetition_TI_S` (`CompetitionInstanceId`,`Status`),
  KEY `IDX_CreatedDate` (`CreatedDate`),
  CONSTRAINT `fk1` FOREIGN KEY (`CompetitionInstanceId`) 
    REFERENCES `CompetitionInstance` (`CompetitionInstanceId`)
) ENGINE=InnoDB AUTO_INCREMENT=74011154 DEFAULT CHARSET=utf8

当出现如下所示的更新时：

update VisitorCompetition 
set    
    Status='CLOSED',
    score=770000,
    visits=null,
    RankAtCompletion=null,
    sharedDate=null,
    LastModifiedDate=current_timestamp(6),
    ModifiedBy='11.12.12.200' 
where VisitorCompetitionId=99999965 and Status = 'CLOSED';

注意where子句中的PK和附加字段作为条件。此更新每秒执行约20次。在大多数情况下，此更新会立即运行，但每天只有几次需要100-300秒才能完成，并且显示为慢速日志。这种行为的原因是什么

更新#1:排除了检查点、触发器和查询缓存作为可能的根本原因。事件\u阶段\u历史\u long为其中一个更新显示了以下内容：

stage/sql/updating      188.025130
stage/sql/end   0.000004
stage/sql/query end     0.000002
stage/sql/closing tables        0.000004
stage/sql/freeing items 0.000002
stage/sql/logging slow query    0.000032
stage/sql/cleaning up   0.000001

类似的问题（但不完全是我的情况）：

---

更新#2:在我的例子中，缓慢的更新总是与互斥争用中的峰值相关。这似乎是根本原因。

虽然有很多原因，但我想谈谈我的案例的根本原因。这是一个应用程序错误，数百个应用程序会话试图更新相同的行，导致锁升级、互斥争用以及执行缓慢。在我们的开发团队修复了代码之后，这个问题立即得到了解决。谢谢大家。

可能您达到了innodb日志文件大小的限制，它不得不暂停以对脏页进行硬刷新。旧版本MySQL的默认日志文件大小对于生产使用来说小得离谱！如果是这样的话，我会检查这一点，并获得胜利。MySQL的哪个版本？有没有其他慢查询与此重叠？@Rick James:MariaDB 10.0.12。还有一个查询（INSERT也会显示，需要约150秒才能完成）。然而，INSERT对一个列使用了随机UUID，该列上有唯一的索引，因此我将其性能缓慢归咎于索引维护（可能不是这样）