2

ゲームのハイスコアを保存するテーブルがあります。このゲームには多くのレベルがあり、スコアはスコアDESC（インデックス）で並べ替えられます。レベルはレベルIDです。このレベルID列でパーティションを作成すると、多くの個別のレベルテーブル（レベルIDごとに1つ）を作成するのと同じ結果が得られますか？何千万ものエントリを期待しているので、レベルデータを何らかの方法で分離するためにこれが必要です。テーブルを正規化したまま、パーティション分割によってこのプロセスを高速化できると聞きました。

また、ゲーム内のレベルの数が不明です（レベルはいつでも追加または削除される可能性があります）。このレベルID列でパーティションを作成するように指定し、新しい（個別のレベルID）がハイスコアテーブルに追加されたときに新しいパーティションを自動的に作成することはできますか？10の個別のレベルから始めて、最終的に50になる場合がありますが、すべてのデータは1つのテーブルに保持されますが、多くのパーティションがありますか？これを機能させるには、レベルIDにインデックスを付ける必要がありますか？

よろしくお願いします！

4

2 に答える 2

1

1つの列にインデックスを作成するのは良いことですが、2つの列を含むインデックスを作成することは、提供した情報に基づいたより良い解決策になります。私は実行します

alter table highscores add index(columnScore, columnLevel);

これにより、パフォーマンスが大幅に向上します。データベースの観点からは、探しているハイスコアに関係なく、データベースはそれらを検索する場所を認識します。

その点で、可能であれば（そして、mysamiテーブルを使用している場合）、次を実行することもできます。

alter table order by columnScore, columnLevel;

これにより、すべてのデータがグループ化されるため、データベースは各ビットがどこにあるかを認識していても、近くで互いに属するすべてのレコードを見つけることができます。つまり、ハードドライブの作業が少なくて済み、結果が速くなります。

その2番目の操作も、大きな違いを生む可能性があります。仕事中の私のPC（90年代に範囲のトップだった恐ろしい古いマシン）には、私が構築した数百万のレコードを含むデータベースがあります-巨大なものはなく、インデックスを含む約2.5GBのデータ-パフォーマンスは低下していましたが、インデックスのデータにより、クエリ時間がクエリあたり約1.5分から約8秒に改善されました。これは、データを含むすべてのセクターに到達できるハードドライブの速度によるものです。

于 2012-08-13T08:17:31.267 に答える
0

さまざまなユーザーのデータを保存する場合は、2つのテーブルを用意するのはどうでしょうか。1つはさまざまなレベルに関するすべての情報を含み、もう1つはユーザーごとに1つの行を持ち、XML/jsonのスコアを示します。

于 2012-08-13T08:17:12.020 に答える