web-dev-qa-db-ja.com

10GB以上のInnoDBテーブルにインデックスをドロップするには4時間以上かかります

これは私が扱っているテーブルです：

CREATE TABLE IF NOT EXISTS `checklist_answer` (
  `id` varchar(36) NOT NULL,
  `created_by` varchar(36) NOT NULL,
  `date_created` datetime NOT NULL,
  `updated_by` varchar(36) NOT NULL,
  `date_updated` datetime NOT NULL,
  `deleted` int(11) NOT NULL,
  `checklistresponse_id` varchar(36) NOT NULL,
  `question_id` varchar(36) NOT NULL,
  `questionoption_id` varchar(36) DEFAULT NULL,
  `value` varchar(256) NOT NULL,
  `source` int(11) NOT NULL,
  `award_id` varchar(36) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `checklist_answer_1f92e550` (`question_id`),
  KEY `checklist_answer_35e0d13d` (`questionoption_id`),
  KEY `answerset` (`checklistresponse_id`,`deleted`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

現在、テーブルには約2,000万行があり、約12GBです。新しいインデックスを追加したり、インデックスを削除したりしようとすると、最低4時間かかります。私が間違っていることを明白にする何かがありますか、それともそれがどのようであるか？

MySQL 5.1.49

ありがとう！

mysqlperformanceinnodb
4
Toby

MySQL 5.1の組み込みInnoDBを使用している場合、インデックスの作成と削除は非常に遅くなります。これは5.5で 高速インデックス で対処されました。可能であればMySQLを更新してください。または、 5.1からの組み込みInnoDBをInnoDBプラグインに置き換えます （これはすでに行われているはずですが、この問題が発生していることを考えると、おそらく何らかの理由でそうではありませんでした）。

3
Michael Hampton

インデックスを作成している3つの36バイトの「ID」フィールドを見てください。

まず、これら3つを8バイトのUNSIGNEDBIGINTに減らすことをお勧めします。 40億の数値が十分に大きい場合、4バイトのUNSIGNEDINTはさらに優れています。

4バイトのINT「削除済み」フィールドがフラグとして使用されている場合、これを1バイトのTINYINTに変更できます。

次の発行を試すことができます。

他の机 checklist_answerキーを無効にする;

/ *

 Make you table changes in here.

* /

他の机 checklist_answerキーを有効にする;

一緒に、私は「4時間」が半分に短縮されたのを見ても驚かないでしょう。

その他のパフォーマンス-ここでのキラーは次のとおりです："ENGINE = InnoDB DEFAULT CHARSET = utf8;"。

これを次のように変更します： "ENGINE = MYISAM DEFAULT CHARSET = latin1;"時間を再び半分に減らすことができます。

BIGINTは、32ビットマシンのパフォーマンスキラーです。 64ビットマシンは、32ビットマシンよりも2.5倍高速にMariaDBを実行します。

1
FWI