1

基本的に、私はこの簡単なクエリを持っています:

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

1秒かかります。

このテーブル (beststat) には現在~1mil のレコードがあり、そのサイズは68MBです。私は4GB の RAMとinnodb buffer pool size= 104,857,600を持っています: Mysql : 5.1.49-3

これは私のデータベースで唯一の InnoDB テーブルです (他は MyISAM です)

もちろん、私はunique key index最高と期間を持っています：

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

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

助けはありますか？

4

2 に答える 2

0

初めて innodb テーブルにアクセスするときに表示される時間には、インデックス データをバッファー プールにロードするのにかかる時間が含まれます。さらなる解雇のタイムラインを検討してください。

公開した詳細が数秒以降のクエリ実行タイムラインのみの場合、

テーブルが FRAGMENTED か NOT かをチェックします。断片化されたテーブルの場合、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

最後に、PROFILING 情報に移動し、SQL_NO_CACHE を使用してクエリcontinuouslu を実行しているときに、サーバー [sar OR iostat] の IO を確認します。

于 2012-05-12T15:29:37.097 に答える
0

更新を行うには、クエリでテーブル全体をスキャンする必要があります。

(bestid, period) に複合インデックスを追加するか、ID を使用するようにクエリを変更します。

于 2012-05-12T15:09:39.163 に答える