私たちのデータベースが私たちの実働システムで大きなボトルネックになっていることに気付いた後、私は問題の一番下に到達するための簡単なベンチマークを作成することにしました。InnoDBボトルネック：ACIDをリラックスしてパフォーマンスを向上させる
ベンチマーク：InnoDBテーブルの同じ行を3000回増分するのにかかる時間（インデックスの主キーによって行がインデックス付けされ、更新される列がインデックスに含まれない場合）。私は、リモートマシン上で稼働する20の同時クライアントを使用して、これらの3000の更新を実行します。それぞれのクライアントは、それぞれ独自のDB接続を備えています。
私がベンチマークしたさまざまなストレージエンジンInnoDB、MyISAM、およびMEMORYには、なぜそのようなプロファイルがあるのかを学ぶことに興味があります。私はInnoDBがなぜそれほど貧弱でもないのか理解したいと思っています。
InnoDB（同時クライアント20人）： 各アップデートには0.175秒かかります。 すべての更新は6.68秒後に行われます。
MyISAM（同時クライアント20人）： 各アップデートには0.003秒かかります。 すべての更新は0.85秒後に行われます。
メモリ（同時クライアント20人）： 各アップデートには0.0019秒かかります。 すべての更新は0.80秒後に行われます。
同時性がこの現象を引き起こしている可能性があると考えて、1つのクライアントで100個の更新を順次実行するベンチマークも行いました。
InnoDB： 各アップデートには0.0026秒かかります。
MyISAM： 各アップデートには0.0006秒かかります。
メモリ： 各アップデートには0.0005秒かかります。
実際のマシンは、ほとんどがデフォルト設定のAmazon RDSインスタンス（http://aws.amazon.com/rds/）です。
私は答えが次の行に沿っていると推測しています：各更新後のInnoDB fsyncs（各更新はACID準拠のトランザクションなので）ですが、MyISAMはトランザクションをサポートしていないためです。 MyISAMはおそらくメモリ内のすべての更新を実行しており、定期的にディスクにフラッシュします。これは、その速度がMEMORYストレージエンジンに近づく方法です。これがそうであれば、InnoDBをトランザクションサポートに使用する方法がありますが、いくつかの制約（構成による）を緩和して、書き込みが耐久性を犠牲にして速く行われるようにしますか？
また、クライアント数が増えるにつれてInnoDBのパフォーマンスを向上させる方法に関する提案はありますか？他のストレージエンジンよりも明らかにスケーリングが悪いです。
更新
私は私が探していたものを正確である、https://blogs.oracle.com/MySQL/entry/comparing_innodb_to_myisam_performanceを発見しました。 innodb-flush-log-at-trx-commit = 2を設定すると、停電やサーバクラッシュが発生した場合のACID制約（ディスクへのフラッシュは1秒に1回発生）を緩和できます。これにより、MyISAMと同様の動作が得られますが、InnoDBで利用可能なトランザクション機能の恩恵を受けます。
同じベンチマークを実行すると、書き込みパフォーマンスが10倍向上しています。
InnoDB（同時クライアント20人）： 各アップデートには0.017秒かかります。 すべての更新は0.98秒後に行われます。
他の提案はありますか？
myisamは、設計上、ACIDに準拠していません。 InnoDBはです。制約を緩和すると、それはもはやACIDに準拠しなくなり、innodbを使用しないこともあります。 –
あなたは*取引を使用しています...そうですか？トランザクションが完了すると、InnoDB *はACIDの「D」を保証するためにハードウェアフラッシュを実行する必要があります（http://en.wikipedia.org/wiki/ACID#Durability）。高速ACIDデータベースでさえ、「標準」スピンドルディスクで約30-50 *トランザクション* /秒**に制限されています。 （しかし、何千ものアップデート* /秒を得ることは難しくありません。違いがあります。） –
ACIDに完全準拠する必要はありません。しかし、トランザクション分離のような機能のために弱い形のACI（Dなし）が必要な場合はどうすればよいでしょうか？私たちのデータはあまり敏感ではないので、マルチAZでAmazon RDSを使用しています。まれなクラッシュや停電は懸念事項ではありません。 – BrainCore