0

80lacのレコードを持つメインテーブルがあります(たとえば、TABLE:MAIN_TABLE)6か月で登録される約10の基準に一致するすべてのレコードを見つける必要がある多くのクエリを実行したい(11 lac)

2列(col1、col2)に複合インデックスを作成しましたが、クエリの実行時間は約30〜50秒です。

このテーブルには約12のインデックスと約60の列があります。Explainを使用すると、5102行が検査され、その使用インデックスが表示されます。

私が使用するソリューション:このテーブルでクエリを実行すると、インデックスが1つだけで、過去6か月のレコードと限られた列(12)を持つ新しいテーブル(MAIN_TABLE_ACTIVE)を挿入するトリガーを作成することにしました。結果は2の順序で表示されます。 -6秒。

質問:80lacの代わりに11lacのテーブルを使用するので、これは最良のアプローチですか?

欠点:トリガーのオーバーヘッド:-(

新しいアプローチを提案するか、この問題の私のアプローチについてコメントしてください。

4

2 に答える 2

0

リアルタイムでデータを表示する必要がない場合は、必要なデータを含む別のテーブルを使用できます(トリガーを使用して作成しているテーブルと同様)。このミニテーブルには、毎日のcronを入力できます。

データをリアルタイムで表示する必要がある場合は、このテーブルでのリアルタイムの計算は適切ではないため、スキーマを再検討する必要がある場合があります。

于 2012-10-04T17:54:06.863 に答える
0

同じテーブルを使用して、インデックスの順序でレコードをフェッチしていることを確認しました

于 2012-10-05T19:37:44.137 に答える