MySQL更新時間過長

經過我們服務的一些預期增長之後，突然間一些更新需要很長時間，這些過去非常快，直到表達到約2MM的記錄，現在它們需要大約40-每個60秒。MySQL更新時間過長

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)

來源

2009-10-26 webclimber

'field1'和'id'字段的類型是什麼？ –

您可以嘗試分析此隊列。請參閱http://dev.mysql.com/tech-resources/articles/using-new-query-profiler.html –

看起來奇怪 - 1行匹配，但零行受到影響？ –

有沒有辦法，查詢應該需要很長的時間，如果ID是真正的主鍵（除非你有很多很多ids等於2229230？）。請運行以下兩個sql語句和後的結果：

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

更新：剛纔是完整的，也做了

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

來源

2009-10-27 00:12:37

+1它肯定會有助於查看是否存在不正確的表格定義，如果在此信息中引發了有關如何優化或修復的信息，請參閱以下信息： – Zak

我可以推薦，以及：

OPTIMIZE TABLE table1;

有時候你的表只需要一點點愛，如果它們迅速增長，而且你沒有在一段時間內優化它們，那麼指數可能會有點瘋狂。事實上，如果你有時間（和你），它絕不會傷害在

REPAIR TABLE table1;

來源

2009-10-27 00:22:25 Dereleased

做一點事？或運行它們是唯一的選擇？ – webclimber

@webclimber - 本地運行會告訴你。 – Phil

追查這個幾個小時後，確定以扔，看來原因是「複製指數」，創建表，我是做回答基思，有這個奇怪的組合：

上fieldx
密鑰的唯一鍵上fieldx

第二個顯然是多餘的，無用的，但是在我下降之後關鍵所有更新回到< 1秒。

+1給基思和伊萬作爲他們的評論幫助我終於找到問題。

來源

2009-10-27 02:22:39 webclimber

對我的幫助是將引擎從'innodb'改爲'myisam'。我對類似大小數據集的更新查詢從100毫秒變爲0.1毫秒。

請注意，更改現有應用程序的引擎類型可能會產生後果，因爲InnoDB具有更好的數據完整性和應用程序可能依賴的某些功能。

對我來說，在大數據集上增加1000倍的速度會讓InnoDB失去價值。

來源

2012-12-28 07:48:32 Kapytanhook

將應用程序從InnoDB更改爲MyISAM可能很危險。 MyISAM幾乎不提供數據完整性保證。 –

好的一點，我會在我的答案中加上這一點，在應用程序由人員設置引擎類型的情況下，很高興知道在某些情況下可以犧牲數據完整性來提高速度。 – Kapytanhook

我碰到過同樣的問題，原來是由於桌面上的觸發器。任何時候在我的表上進行更新時，觸發器都會更新另一個表，這是延遲實際上造成的。在該表上添加索引可解決問題。因此，請嘗試檢查表格上的觸發器。

來源

2017-01-31 06:19:05

與select語句版本相比，在調試update語句時花費太多時間需要考慮的另一件事是：是在事務中執行的更新語句嗎？

在我的情況下，事務將更新語句從極快的執行時間轉換爲極其緩慢的執行時間。受影響的行越多，性能的損失就越重。我的陳述與用戶定義的變量一起工作，但不知道「問題」的那部分。

來源

2017-09-20 14:18:45 Piemol

MySQL更新時間過長

回答

相關問題