0

データベースタイプ:mysql

列:日付、時刻、price1、qty1、price2、qty2の時刻は、1か月のレコード数が約550万ミリ秒になります。

日付は一意ではないため、主キーとして選択することはできませんが、日付と時刻を組み合わせて選択することはできますが、それもお勧めできません。

「この日時」と「その日時」の間で価格と数量の選択などのクエリを実行すると、結果は数百万の範囲になる可能性があります。

主キー、インデックス、および代理キーに関して最良の選択となる可能性があるものと、これを実装するための最良の方法は何ですか。データベースをどのように最適化する必要がありますか。

4

2 に答える 2

0

日付と時刻の両方を選択するのは悪い考えだと言う理由がわかりません(複合キーに反対していますか?)

あなたにとってのより大きな問題は、時間がミリ秒を保存しないということです。詳細については、このバグを参照してください:http: //bugs.mysql.com/bug.php?id=8523

また、ティッカーなどの株式を識別するキーに何かが欠けているようです。ティッカーは時間の経過とともに変化する可能性があるため、StockIDなどのサロゲートを導入することをお勧めします。これは、Stockなどと呼ばれるテーブルで行います。

次に、Tradeテーブルに、StockID、Date、Timeを使用することをお勧めします(ただし、ミリ秒を保存できるように、TIMEデータ型以外の場所に時間を保存します。サポートが必要な場合は別の質問をしてください)。

PK内のキーの順序は、保存と取得の両方にとって重要です。検索では、クエリに対して最も選択的なキーを最初に配置する必要があります。したがって、株式(または株式のセット)のすべてのデータに一度にアクセスする傾向がある場合は、インデックスを使用してそれらをすばやく見つけることができるように、StockIDを最初に配置します。特定の間隔ですべてのデータにアクセスする傾向がある場合は、最初に[日付]、[時刻]の順に入力します。

ストレージについては、追加する方がよいので、ここでも日付と時刻を最初に設定することをお勧めします。

主に日付範囲でアクセスしたいが、場合によってはストックでアクセスしたい場合は、StockIDにセカンダリインデックスを設定します。

于 2010-12-30T21:42:23.220 に答える
0

自然キーがないため(各行内で一意のものはありません)、代理キーを追加する必要があります(引数「transactionid」のため)。効率的な期間スキャンのために、日時に基づいてインデックスを作成することもできます(実際には、単一の列である必要があります)。

于 2010-12-30T17:00:11.510 に答える