2011-01-29 77 views
12

我有以下InnoDB表:mysql的慢插入

+-----------+-----------+------+-----+-------------------+----------------+ 
| Field  | Type  | Null | Key | Default   | Extra   | 
+-----------+-----------+------+-----+-------------------+----------------+ 
| id  | int(11) | NO | PRI | NULL    | auto_increment | 
| doc_id | char(32) | NO |  | NULL    |    | 
| staff  | char(18) | NO |  | NULL    |    | 
| timestamp | timestamp | NO | MUL | CURRENT_TIMESTAMP |    | 
+-----------+-----------+------+-----+-------------------+----------------+ 

隨着這些鍵:

+--------------+------------+-----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ 
| Table  | Non_unique | Key_name  | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | 
+--------------+------------+-----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ 
| staff_online |   0 | PRIMARY   |   1 | id   | A   |  277350 |  NULL | NULL |  | BTREE  |   | 
| staff_online |   1 | timestamp  |   1 | timestamp | A   |  277350 |  NULL | NULL |  | BTREE  |   | 
| staff_online |   1 | staff_timestamp |   1 | timestamp | A   |  277350 |  NULL | NULL |  | BTREE  |   | 
| staff_online |   1 | staff_timestamp |   2 | staff  | A   |  277350 |  NULL | NULL |  | BTREE  |   | 
+--------------+------------+-----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ 

我只注意到in mysql-slow.log我有時對這個表,需要超過1的INSERT查詢第二個

INSERT INTO `staff_online` (`doc_id`, `staff`, `timestamp`) VALUES ('150b60a0ab8c5888bdbbb80bd8b7f8a2', 'asia', '2011-01-29 16:52:54') 

我真的很困惑爲什麼需要這麼長時間。我如何加快速度?

順便說一句:每一天都有〜80緩慢插入和40這樣慢的更新。

+1

表中有多少行,你確定所有的插入都很慢? – 2011-01-29 16:27:15

+1

有277259行,只有一些插入緩慢(罕見)。 – kalkin 2011-01-29 16:33:36

+7

你似乎有兩個索引,一個靠`timestamp`,另一個靠`timestamp,staff`。後者足以通過'timestamp'進行搜索,您可以刪除前者。 – 9000 2011-01-29 17:00:20

回答

10

有時不是查詢本身會導致放緩 - 在表上運行的另一個查詢可能會因事務隔離和鎖定而容易導致插入速度變慢。您的緩慢查詢可能只是等待其他事務完成。這在忙碌的桌子上很常見,或者如果您的服務器正在執行長/複雜的交易。

另一個重要因素將是數據庫的整體性能:您的my.cnf文件如何調整,服務器本身如何調整,服務器上運行着什麼以及服務器運行的是什麼硬件。

Linux工具mytop和查詢SHOW ENGINE INNODB STATUS\G可能有助於查看可能的故障點。一般的Linux性能工具也可以顯示您的磁盤有多繁忙等。

鑑於此表的性質,您是否考慮了一種備用方式來跟蹤誰在線?在MySQL中,我過去曾使用過MEMORY表。 NoSQL數據存儲可能也適用於此類信息。 Redis可以將此存儲爲一個有很多成功(分數==時間戳)的排序集。

延伸閱讀:

4

如果您以大密度爆發插入表中,可能需要一些時間進行清理,例如,爲表和索引分配更多空間。

如果不希望您的應用等待,請嘗試使用INSERT DELAYED,儘管它有其不利之處。

12

有277259行,只有一些刀片是慢(罕見)

每當B樹頁是滿的,它需要被拆分這需要一些時間。由於每個插入更新所有索引,因此插入性能也會越慢,索引越多。 9000已經正確地陳述了您的(時間戳,員工)索引涵蓋了95%的案例中的(時間戳)索引,但爲了獲得更好的性能,需要單列(時間戳)索引的情況非常罕見。

還有一些週期性的後臺任務,偶爾會在一天中減慢插入或兩個插入。

此外,延遲的另一個原因是數據庫活動。如果您的事務處理是插入需要更新(或分頁)的鎖定頁面,則插入必須等待,直到寫入鎖定被默認爲止。這些其他活動甚至不需要真正開始交易,甚至不必讀取競爭;您還可以擁有寫入爭用或由繁重活動構建的隊列。

最後一個可能的原因 - 數據庫服務器資源不足,無論是內存還是CPU或網絡I/O。只有這麼多的服務器可以做,所以它必須等到它有足夠的資源。

1

如果你恰巧是在你的MySQL安裝後備級別,我們注意到有很多那種緩慢的當使用4.1版時。