MyISAMのパフォーマンス

テーブルの変更の追跡のためのMySQL（5.7以降）では、this approachは実装が非常に簡単です。
しかし、テーブルレベルのロックを行うMyISAMのバージョンテーブルが必要です。
1秒ごとに複数の挿入/更新が行われるプロダクションシステムでは、このアプローチはうまくいくのでしょうか？
このアプローチについて実際の生産システムの経験はありますか？

DB（InnoDBテーブル）の各テーブルには、自分のシステムには、以下の負荷を有するバージョンテーブル（MyISAMテーブル）を有しています。
*さまざまな結合のために各テーブルで約500読み取り/秒。
*バージョンテーブルへのトリガーを持つさまざまなテーブルに対して、50書き込み/秒。
バージョンテーブル（MyISAM）はパフォーマンス上のボトルネックになりますか？MyISAMのパフォーマンス

出典

2017-07-21 aadidasu

私はこのタイプの高性能なMyISAMシナリオを直接経験していませんが、MyISAMは大丈夫です*あなたがテーブルとサーバーを適切にセットアップしたと思います。私は静的フィールド、適切なインデックスを使用することについて話しています。このパフォーマンスが必要なタスクには専用サーバーを使用することもできます。MyISAMはうまくいくと思います。また、ハードドライブではなくSSDでデータベースを設定することもできます。 – Dennis

ここでMyISAMの唯一の理由は、増分を取得することです。ですから、InnoDB（ステータステーブル/カラム、または単にインクリメントの代わりにタイムスタンプなどを使って）でそれを行う方法を見ていない時があります。あなたが失うもの：MySQL 8では動作しません（もうMyISAMはありません）。また、InnoDBトランザクションがロールバックされるたびに（MyISAMでロールバックできないので）無効なバージョンのエントリがあります。一方、パフォーマンスは問題ではないはずです。そうであれば、それを破ることができます。テーブル/サーバ1/2に奇数/偶数IDのバージョンを入れてください。とにかく、私のポイントは：MyISAMは死んでいます。安心してお休みください。 – Solarflare

MyISAMストレージエンジンは完全なテーブルロックを実行します。読み取りと書き込みを同時に行うことはできません。この特定のテーブルにアクセスする他のすべてのセッションは、更新が完了するまで待つ必要があります。 InnoDBはこれを間違いなく解決します。多くの書き込みを行うプロダクションシステムでは、query_cacheをオフにする必要があります。クエリキャッシュサイズが大きすぎると、パフォーマンスが大幅に低下します。キャッシュオーバーヘッドとロックのためです。キャッシュ可能なクエリは、MySQLのクエリキャッシュで排他ロックを解除します。 – xachela

MyISAMテーブルにAUTO_INCREMENT（あるモードセット）があり、他のUNIQUEキーがない場合は、「ロックなし」テーブルに追加されます。だから、私は50の書き込み/秒が問題になるとは思わない。

MariaDBには、Oracleがジェットシップした後も、おそらくMyISAMが長く続きます。オラクルの目的は、InnoDBを非常に優れたものにしてMyISAMを必要とせず、成功する可能性が高いことです。

バージョンテーブルのセカンダリインデックスがボトルネックになります。この分野では、InnoDBの「バッファの変更」がMyISAMの「今すぐ」よりも優れていると思います。

出典

2017-07-22 16:02:48

答えて

関連する問題