サーバを運用しています。パフォーマンスはまた、最新バージョン(5.5)で向上しています。20%ほどパフォーマンスが上がります。ディストリビューションにおいてデフォルトで有効になっています。編集し、次の行をコメントアウトします。サーバを再起動します。トランザクションごとのディスク書き込みの回避デフォルトでは、MySQLは各接続開始時のautocommitの値を1にしています。MyISAMの場合、更新結果がディスクに保存されることを保証していないため、この設定はそんなに悪い設定ではありません。InnoDBの場合、InnoDBテーブルへのあらゆるinsert/update/deleteによって、ディスクへの書き込みが発生するということを意味します。そんなことはありません。ディスクへの書き込みは何らかのcommitment後、データベースが障害後再起動したときもデータが存在することを保障します。問題は、DBのパフォーマンスがディスクの物理的な速度によって制限を受けることです。書き込みを確認する前にデータをディスクに書き込まなければならないことを考えると、少し時間がかかるでしょう。ディスクの書き込みに平均9msかかるとすると、おおよそ1秒当たり67コミットに制限されます。これは非常に遅いです。ディスクのあるセクタに書き込み中は、そのセクタを読み込むことはできません。InnoDBはこれらの制限のいくつかを複数の書き込みを同時に実行することで回避しています。それでも制約が存在します。システムによる“自動”書き込み(およそ1秒ごとに書き込みを行う)を利用することで、各トランザクションが完了するたびにディスクへ書き込むことを回避することができます。問題が発生した場合、最近1秒のデータが失われますが、パフォーマンス向上を得ようとしていることを考慮すれば、許容できる範囲でしょう。大きさシステムに搭載された物理メモリ量に依存しますが、非常に重要なグローバル変数であり、これを設定することでDELETEおよびSELECTの実行速度が改善されます。5.0では、各InnoDBテーブルとそのインデックスごとにデータファイルを生成し保存することができます。tablespace」と呼ばれています。tablespaceを使用することで、特定のテーブルを別の物理ディスクに移動したり、他のInnoDBテーブルの利用を妨げることなくあるテーブルをバックアップから復元したりするのに役に立ちます。tablespaceを有効にすることができます。[mysqld]innodb_file_per_tableサーバ再起動後、InnoDBは新規に作成されたテーブルをそのテーブルが属するデータベースディレクトリ内にあるname_table.ibdという名前のファイルに保存します。これはMyISAMストレージエンジンの動きと似ていますが、MyISAMはテーブルをデータファイルtbl_name.MYDとインデックスファイルtbl_name.MYIに分割して保存します。InnoDBのデータとインデックスは.ibdファイル内に一緒に保存されます。tbl_name.frmファイルは通常通り作成されます。my.cnf中のinnodb_file_per_tableの行をコメントアウトし、サーバを再起動すると、InnoDBは再び共有テーブルスペースファイルにテーブルを作成します。innodb_file_per_tableはテーブル作成にのみ影響します。このオプションを有効にしてサーバを起動すると、新規テーブルは.ibdファイルを使用する状態で作成されますが、共有テーブルスペース内にあるテーブルにアクセスすることも可能です。tablespaceを使用しているテーブルにアクセスすることも可能です。(tm)と同様、時間がたつにつれ、性能が劣化していきます。これは大きなテーブルに対してデータの削除と追加を続けることによって発生するデータのフラグメンテーションによるものです。大量のトラフィックが発生する大きな環境において、性能の改善および劣化を防ぐ非常に簡単な方法があります。それは定期的にデータベースの再構築を実施することです。そのために、1時間程度のサービス停止を計画すべきです。tentacleサーバはデータを受け取れるようにしておき、サーバが復旧次第データを処理できるようにします)サービス停止後、データベースのダンプを取得(エクスポート)します。password:データベースを削除します。sec)データベースを作成し、先ほどエクスポートしたデータをインポートします。/tmp/pandora3.sql1500エージェントと約100,000モジュールからなるシステムで、この処理全体で10~30分かかります。システムが巨大だったり、ハードウェアの性能が劣っている場合は、それ以上かかるでしょう。この処理は自動化可能ですが、細心の注意が必要なため、毎月もしくは半月に一度、手動で実行することをお勧めします。パフォーマンスを最適化できるいくつかの場合があります。以下のインデックスの最適化はグラフ生成を(とても)高速化しますが、多くのディスクスペースを必要とします。スロウクエリいくつかのシステムでは保持している情報によって、通常よりもシステムのパフォーマンスが悪いスロウクエリが見られることがあります。テーブルを最適化するために、(システムのパフォーマンスに影響する)一定時間を超えたこのタイプのクエリをログに記録するようにできます。これを有効にするには次のようにします。編集し、次の設定を加えます。mysql_slow.logコマンドラインから次のように設定します。OPTIMIZEツールを使用するというのがあります。tagente_estado;この作業によって、パフォーマンスが改善されるでしょう。この作業は1週間に複数回実行する必要はありません。システムが稼働中にさっと完了するでしょう。巨大な環境においては、OPTIMIZEコマンドがブロックされるかもしれません。このような場合、一番よい代替案はDBの再構築です。これらの作業を実施した後、以下のコマンドを実行すべきです。TABLEにマップされており、インデックス統計の更新とクラスタされたインデックス内の使用されていないスペースを解放するためにテーブルが再構築されます。設定例1このサンプル設定は4CPU、4GBメモリのサーバに2個のInnoDBデータベース(どちらも頻繁にアクセスされる)を作成したシステムで利用する想定で作成しました。各変数に割り当てたメモリの合計がシステム全体のメモリ量の80%を超えないよう注意してください。起動したMySQLサーバの状況を確認し、インストールしたシステムにあわせて調整してください。パフォーマンスを評価するための一般的な見方として、以下の事項がパフォーマンスに大きく影響することに注意しましょう。pandorafms.org。