PK上的表更新和MySQL中的另一個字段偶爾很慢

這是MySQL中的UPDATE偶爾很慢的有趣情況。背景：48GB Innodb緩衝區緩存，512MB ib日誌。 Innodb表，40毫升行。結構和索引：PK上的表更新和MySQL中的另一個字段偶爾很慢

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';

注PK where子句和附加字段作爲條件。此更新執行約20次/秒。在大多數情況下，此更新即時運行，但每天幾次需要100-300秒才能完成，並且顯示爲慢日誌。這是什麼原因造成的？

更新＃1：排除了檢查點，觸發器和查詢緩存作爲可能的根本原因。 events_stages_history_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

類似的問題（但不完全是我的情況）：MySQL update taking(too) long time

更新＃2：在我的情況下，更新速度慢始終與互斥爭尖峯相關。似乎這是根本原因。

來源

2017-08-18 Dmitry Buzolin

也許你碰到了你的innodb日誌文件大小的限制，它不得不停下來做一個髒頁面的硬盤刷新。在較早版本的MySQL中，默認的日誌文件大小對於生產使用而言是小得可笑的。 –

閱讀https://www.percona.com/blog/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/和https://dev.mysql.com/doc /refman/5.6/en/innodb-data-log-reconfiguration.html –

偉大的一點，比爾！如果是這種情況，我會檢查這一點並得分。 –

雖然可以有很多原因，但我想提一下在我的情況下是什麼原因。這是一個應用程序錯誤，其中數百個應用程序會話嘗試更新相同的行，從而導致鎖升級，互斥量爭用以及結果執行速度緩慢。在我們的開發團隊修復了代碼後，這個問題立即得到解決。謝謝大家。

來源

2017-10-06 15:41:27

PK上的表更新和MySQL中的另一個字段偶爾很慢

回答

相關問題