使用NOW（）執行非常緩慢的MySQL更新

在過去的幾天裏，我觀察到一個簡單的更新查詢執行得非常糟糕。更新時間範圍從2.5秒到15秒。查詢已工作性能極限（< 1秒）在過去的一年半之內，但突然開始出現在最後兩天的性能下降。任何見解將不勝感激。使用NOW（）執行非常緩慢的MySQL更新

update user.auth_token 
set last_access_time = NOW() 
where token = '488f4f040090f1cb749e09a514d3dd3d';

該表只包含9行並具有以下定義。

CREATE TABLE `auth_token` (
    `user_name` varchar(45) NOT NULL, 
    `token` varchar(45) DEFAULT NULL, 
    `last_access_time` datetime DEFAULT NULL, 
    `creation_time` datetime NOT NULL, 
    `token_type` varchar(45) NOT NULL, 
    UNIQUE KEY `token_UNIQUE` (`token`), 
    KEY `fk_user_name_idx` (`user_name`), 
    CONSTRAINT `fk_user_name` FOREIGN KEY (`user_name`) 
     REFERENCES `user` (`name`) 
     ON DELETE CASCADE ON UPDATE CASCADE 
) 
ENGINE=InnoDB DEFAULT CHARSET=utf8;

MySQL的版本是5.5.50-0ubuntu0.14.04.1-log

更新解釋輸出如下：

id, select_type, table, type, possible_keys, key, key_len, ref, rows, Extra 
'1', 'SIMPLE', 'auth_token', 'const', 'token_UNIQUE', 'token_UNIQUE', '138', 'const', '1', ''

來源

2016-09-16 Sandeep Deb

任何更多的數據將不勝感激。例如EXPLAIN計劃。任何額外的索引？表的統計數據？ –

請添加查詢的執行計劃，「NOW」不應減慢查詢速度。 – sagi

性能問題應該包括'EXPLAIN ANALYZE'和一些關於表格大小，索引，當前時間表現，期望時間等的信息。'Slow'是一個相對術語，我們需要一個真正的值來比較。 \t \t [** MySQL **]（http://dba.stackexchange.com/questions/15371/how-do-i-get-the-execution-plan-for-a-view） –

感覺就像令牌的唯一鍵很可能會成爲一個主鍵。

由於沒有一個明確的PK會導致InnoDB的一個隱藏的PK添加到該表，擁有所有二級索引引用隱藏的PK。

每當PK創建它需要一個全局鎖製造無關的問題效果彼此，這都很難找出辦法服務器。

我也想嘗試刪除外鍵，然後再次執行相同的查詢，只是爲了確保未在任何事物的方式獲得。

alter table auth_token add primary key (token), 
         drop key token_unique, 
         drop foreign key fk_user_name;

來源

2016-09-16 18:46:11

謝謝#Andreas。我所做的更改（除了外鍵），並已回來的關鍵路徑查詢。我現在保持在觀察系統，具有已經10分鐘了，我仍然沒有看到mysql-slow日誌中的有問題的查詢，如果這能解決問題，請直到明天再回來。我仍然非常困惑，當系統出現時，這是如何突然冒出來的工作了好幾個月，再次感謝 –

謝謝，這似乎是有效的，你對服務器的全局鎖定的解釋與觀察行爲相符，我也觀察到系統的負載平均值相對較高這個查詢是行爲不端的（大約2.x），但是一旦我放棄了唯一的約束並將其改爲PK，它就下降到預期的0.0x。非常感謝您的建議！ –

使用NOW（）執行非常緩慢的MySQL更新

回答

相關問題