Unix の top または Windows のタスクマネージャで表示されたプロセスの CPU 使用率が 70% 未満である場合、おそらくそのプロセスはディスク処理である。トランザクションコミットの数が多すぎるか、バッファプールが小さすぎることが考えられる。 バッファプールは大きくした方がよいが、物理メモリの 80% を超えないようにする。

複数の変更処理を 1 つのトランザクションにまとめる。InnoDB は、データベースを変更するトランザクションがコミットされるたびにログをディスクにフラッシュする必要がある。一般にディスクの回転速度は最高でも 1 秒間に 167 回転(10000rpmの規格の物の場合)であるため、ディスクがオペレーティングシステムを欺かない限り、コミットの回数も同じく 1 秒間に 167 回に制限される。

最近コミットされたトランザクションの一部を失ってもかまわない場合は、my.cnf のパラメータ innodb_flush_log_at_trx_commit を 0 に設定できる。InnoDB は、いずれにしても 1 秒間に 1 回ログをフラッシュしようとする。ただし、このフラッシュは保証されない。

ログファイルをバッファプールと同じぐらい大きくする。InnoDB は、ログファイルの最後まで書き込むと、チェックポイントでバッファプールの変更された内容をディスクに書き込まなければならない。ログファイルが小さいと、不必要に何度もディスクへ書き込むことになる。大きなログファイルの難点は、リカバリに時間がかかることである。

ログバッファも大きくする必要がある（8 MB など）。

（3.23.39 以降に関係） Linux および Unix の一部のバージョンでは、Unix の fdatasync やその他の類似する方法を使ってファイルをディスクにフラッシュする際に、かなりの時間がかかる。 InnoDB は、デフォルトで fdatasync 関数を使用する。 データベースへ書き込む際のパフォーマンスが不満であれば、my.cnf の innodb_flush_method を O_DSYNC に設定してもかまわない。ただし、ほとんどのシステムでは O_DSYNC の方が処理が遅くなると思われる。

InnoDB にデータをインポートするときは、autocommit がオン(1)になっていないことを確認する。その場合、挿入のたびにディスクへのログのフラッシュが要求される。 SQL の単純なファイルインポート行の前に次の行を追加する。

SET AUTOCOMMIT=0;

さらにその後に次の行を追加する。

COMMIT;

mysqldump のオプション --opt を使用すると、上記のように SET AUTOCOMMIT=0; ... COMMIT; ラッパで囲まなくても、ダンプファイルを取得して InnoDB テーブルに高速でインポートできる。

大量に INSERT する時の大規模なロールバックに注意する。InnoDB は、挿入バッファを使って挿入時のディスク I/O を削減するが、対応するロールバックではそのようなメカニズムが使用されない。ディスクバウンドのロールバックには、対応する挿入の 30 倍の時間がかかる。データベースのプロセスを強制終了しても、データベース起動時に再度ロールバックが開始されるので役に立たない。ロールバックの暴走を回避するには、ロールバックが CPU とメモリだけで高速に実行されるようにバッファプールを拡大するか、InnoDB データベース全体を削除するしかない。

他の大規模なディスクバウンドの操作にも注意する。 DROP TABLE または TRUNCATE（MySQL-4.0 以降）を使用してテーブルを空にする。DELETE FROM yourtable は使用しない。

多数のレコードを挿入する場合は、複数行の INSERT を使用して、サーバとクライアント間の通信にかかるオーバヘッドを軽減する。

INSERT INTO yourtable VALUES (1, 2), (5, 5);

この方法は、InnoDB だけでなく他のテーブル型へ挿入する場合にも有効である。