一個非常簡單的UPDATE InnoDB的查詢佔用過多

基本上我有這個簡單的查詢：一個非常簡單的UPDATE InnoDB的查詢佔用過多

UPDATE beststat 
    SET rawView = rawView + 1 
    WHERE bestid = 139664 AND period = 201205 
    LIMIT 1

這需要1秒。

此表（beststat）目前有〜1mil的記錄，其大小爲：68MB。我有4GB內存和innodb buffer pool size = 104,857,600，具有：MySQL的：5.1.49-3

這是唯一的InnoDB表在我的數據庫（其它的MyISAM）

我

CREATE TABLE `beststat` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
`bestid` int(11) unsigned NOT NULL, 
`period` mediumint(8) unsigned NOT NULL, 
`view` mediumint(8) unsigned NOT NULL DEFAULT '0', 
`rawView` mediumint(8) unsigned NOT NULL DEFAULT '0', 
PRIMARY KEY (`id`), 
UNIQUE KEY `bestid` (`bestid`,`period`) 
) ENGINE=InnoDB AUTO_INCREMENT=2020577 DEFAULT CHARSET=utf8

：對，當然bestid和週期有

EXPLAIN SELECT rawView FROM beststat WHERE bestid =139664 AND period =201205 LIMIT 1

給出：

id select_type table type possible_keys key key_len ref rows Extra 
1 SIMPLE beststat const bestid bestid 7 const,const 1

任何幫助嗎？

來源

2012-05-12 dynamic

執行查詢continuouslu的'LIMIT 1'條款似乎沒有必要。你有沒有在查詢上運行'EXPLAIN'？它是否正確使用索引？ – Ilion

@llion：你無法解釋UPDATE/INSERT查詢。我懷疑極限1影響性能 – dynamic

你可以'解釋選擇rawView從betstat哪裏bestid = 139664和時期= 201205極限1'而不是？使用這種大小的表格，您可以考慮在[bestid]上[分割]（http://dev.mysql.com/doc/en/partitioning.html）。 – eggyal

您的查詢必須掃描整個表格才能進行更新。

在（bestid，句點）上添加複合索引或將查詢更改爲使用id。

來源

2012-05-12 15:09:39

Gorden Linoff ...爲什麼查詢應該掃描整個表，儘管它具有唯一鍵...我不認爲這樣的唯一鍵不會滿足索引需求，因爲它就像PRIMARY鍵，它將允許NULL。請你詳細說明你是否建議如此...... – Uday

戈登：我有一個綜合指數 – dynamic

我的不好。我在查看代碼時顯然錯過了UNIQUE KEY行。我將我的索引與約束分開聲明以避免含糊不清。 –

當您第一次訪問innodb表時，它將顯示的時間包括將索引數據加載到緩衝池所需的時間。考慮進一步發射的時間表。

如果公佈的細節秒，後來查詢執行時間表只，

檢查表是否碎片化與否。如果分割表格的情況下，UPDATE的實際查找量大於。

如果不是這樣，請看下面的變量。

1) innodb_flush_log_at_trx_commit 
    In general there will be 30 - 40% degraded performance with  
    innodb_flush_log_at_trx_commit set to 1 than it is set to 2 

2) innodb_flush_method. 
    Default fsync will perfrom worse than the O_DIRECT and O_SYNC

最後去的分析信息，並在服務器上看到的IO [特別行政區和iostat的]當你與SQL_NO_CACHE

來源

2012-05-12 15:29:37 Uday

一個非常簡單的UPDATE InnoDB的查詢佔用過多

回答

相關問題