2

苦痛が大きくなる前に、 redmineデータベースを最適化しようとしています。変更（基本的にすべてのSVN変更のログ）は137000行（ish）にあり、テーブルは基本的なデフォルト設定に設定されています。キーパッキングなどはありません。

表は次のとおりです

ID int[11] Auto Inc (PK)
changeset_id int[11]
action varchar[1]
path varchar[255]
from_path varchar[255]
from_revision varchar[255]
revision varchar[255]
branch  varchar[255]

インデックス：プライマリ（ID）、
              changeset_idがINDEXBTREEに設定されている

http://forge.mysql.com/wiki/Top10SQLPerformanceTipsからの情報に基づいたlatin1文字セットのすべて

テーブルエンジンはInnoDBですパックキーはデフォルトに設定されています（char varcharのみをパックします）

他のすべてのオプションはオフになっています。

これを最適化するための最良の方法は何ですか？（Bar Truncate; o））

4

2 に答える 2

2

それは、読み取りと書き込みの特性、つまり、作成しているクエリと、それに書き込む頻度に完全に依存します。

書き込みを最適化する方法は、インデックスの数を最小限に抑えることです。理想的には、MS SQL サーバーで単調に増加するキーを持つ「クラスター化インデックス」となるものを使用して、新しいレコードをテーブルの最後に書き込み、他の個別のインデックスを書き込まないようにします。さらに良いのは、トランザクション機能が必要ない場合は、DBMS をスキップして、何らかの単純な古いログ ファイルに書き込むことです。

クエリの場合は、必要に応じて複雑にすることができます。ただし、クエリのためにテーブルから大量のデータが必要な場合 (つまり、キーに基づいて単一のレコードを検索するだけではない場合)、テーブル スキャンはそれほど悪いことではないことに注意してください。一般に、テーブルの内容の 3 ～ 5% 以上を調べる場合、テーブル スキャンは非常に高速になります。繰り返しますが、これに関しては、単純な古いファイルはおそらく DBMS よりも高速です。

両方を最適化する必要がある場合は、書き込み用に最適化し、クエリ用に最適化するコピーを定期的に作成し、コピーに対してクエリを実行することを検討してください。

于 2009-06-05T11:28:36.317 に答える
2

mysql にはいくつかの一般的な最適化手法があります。最初の手法は、データ型が ABC に適合していることを確認することです (こちらを参照)。上から下に行くと、ID と changeset_id は見栄えがよく、action はおそらく varchar ではなく char 1にする必要があります (空白のままにしておくことができる場合は null 可能です (一般に、nullable が他のフィールドで正しく設定されていることを確認してください))。 . 他の 5 つのフィールド (サイズによってはテーブルを支配する可能性があります) については、文字列は正しいデータ型ですか? (私はパス、from_path、ブランチでイエスだと推測していますが、おそらくリビジョンは数字でなければなりません (そうではないので、git などをサポートしていると思います))

また、特に「パス」と「リビジョン」テーブルがそれらのうちの 4 つを正規化するため、それらは正規化ターゲットのように見えます (必要な場合は、ここに基本的なチュートリアルがあります)。

于 2009-06-05T13:19:23.693 に答える