これまでのところ本当にうまく動作しているInnoDBテーブルですべてのサイトを実行します。今私は自分のサイトでリアルタイムに何が起こっているのか知りたいので、各ページビュー（ページ、参照元、IP、ホスト名など）をInnoDBテーブルに保存します。 1秒あたり約100個の挿入があり、このテーブルはログを閲覧している間は一度だけ読み込まれます。MysqlのMEMORYテーブルとInnoDBテーブルの比較（多くの挿入数、読み込み数が少ない）
古いアイテムを取り除くクロンで毎分テーブルを清掃します。これにより、平均で約35,000の行がその表に残されます。サイズは約5MBです。
私はInnoDBテーブルをMEMORYテーブルに転送する方が簡単でしょうか？私が見る限り、これはディスクのIOを大量に節約するでしょうか？ MySQLを再起動するとデータが失われますが、これは私の場合は問題になりません。
質問：私の場合、InnoDBテーブルを上回るメモリテーブルをお勧めしますか？
はいそうです。あなたが言及している条件（多くの書き込み、定期的なデータのパージ、データの永続性は必要ありません）は、MEMORYの理想的な候補になります。
があなたのInnoDBの設定を最適化してください：
限り、あなたは（innodb_buffer_pool_sizeで）あなたのテーブル全体を保持するのに十分なメモリを使用するためにはInnoDBを設定して、同じサーバー上の他のInnoDBテーブルからの過大な圧力がないよう、データはメモリに残ります。書き込みパフォーマンスが懸念されている場合（同じシステムの他の用途がない場合）、innodb_flush_log_at_trx_commit = 0を設定してバイナリログを無効にすることで、書き込みパフォーマンスを大幅に向上させることができます。
一時テーブルで任意の種類のトリガーを使用すると、管理しにくくなり、一時テーブルでトランザクション性の利点が得られません。私はMEMORYテーブルに切り替えた http://dev.mysql.com/doc/refman/4.1/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit
、およびパフォーマンスが良いです：
あなたはここより詳細な情報を見つけることができます。私はロック待機率がちょっと悪いことに気付いた。 Current Lock Wait Ratio = 1：570はTuning-Primerが言うものです。それについて何かできることは何ですか？ –
私はL/W比がサーバー全体の指標であると信じていますので、別の質問でそれを聞いてください。おそらくSOの代わりにhttp://serverfault.com/にもあるでしょう。 – Mchl
ありがとう、私はここにそれを求めた：http://serverfault.com/questions/350364/high-lock-wait-ratio-in-mysql –