3

TimesTenDBクエリの最適化についてサポートが必要です。Javaプロファイラーを使用していくつかの対策を講じたところ、ほとんどの時間がかかるコードセクションが見つかりました（このコードセクションはSQLクエリを実行します）。このクエリが特定の入力データに対してのみコストがかかるのは奇妙なことです。

これが例です。クエリを実行しているテーブルが2つあります。1つはフェッチするオブジェクトを表し（T_PROFILEGROUP）、もう1つは他のテーブルからの多対多リンクを表します（T_PROFILECONTEXT_PROFILEGROUPS）。リンクされたテーブルをクエリしていません。

これらは、DBプロファイラーを実行して実行したクエリです（ID以外は同じです）。

Command> select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1464837998949302272;
< 1169655247309537280 >
< 1169655249792565248 >
< 1464837997699399681 >
3 rows found.

Command> select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1466585677823868928;
< 1169655247309537280 >
1 row found.

これは私がプロファイラーに持っているものです：

12:14:31.147       1 SQL      2L    6C  10825P Preparing: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1464837998949302272
12:14:31.147       2 SQL      4L    6C  10825P sbSqlCmdCompile ()(E): (Found already compiled version: refCount:01, bucket:47) cmdType:100, cmdNum:1146695.
12:14:31.147       3 SQL      4L    6C  10825P Opening: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1464837998949302272;
12:14:31.147       4 SQL      4L    6C  10825P Fetching: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1464837998949302272;
12:14:31.148       5 SQL      4L    6C  10825P Fetching: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1464837998949302272;
12:14:31.148       6 SQL      4L    6C  10825P Fetching: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1464837998949302272;
12:14:31.228       7 SQL      4L    6C  10825P Fetching: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1464837998949302272;
12:14:31.228       8 SQL      4L    6C  10825P Closing: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1464837998949302272;
12:14:35.243       9 SQL      2L    6C  10825P Preparing: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1466585677823868928
12:14:35.243      10 SQL      4L    6C  10825P sbSqlCmdCompile ()(E): (Found already compiled version: refCount:01, bucket:44) cmdType:100, cmdNum:1146697.
12:14:35.243      11 SQL      4L    6C  10825P Opening: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1466585677823868928;
12:14:35.243      12 SQL      4L    6C  10825P Fetching: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1466585677823868928;
12:14:35.243      13 SQL      4L    6C  10825P Fetching: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1466585677823868928;
12:14:35.243      14 SQL      4L    6C  10825P Closing: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1466585677823868928;

最初のクエリがほぼ100ミリ秒かかったのに対し、2番目のクエリは即座に実行されたことは明らかです。これは、クエリのプリコンパイルに関するものではありません（同じクエリが以前に発生したため、最初のコンパイルもプリコンパイルされます）。ここで使用されるすべての列のDBインデックスがあります：T_PROFILEGROUP.M_ID、、。T_PROFILECONTEXT_PROFILEGROUPS.M_ID_OIDT_PROFILECONTEXT_PROFILEGROUPS.M_ID_EID

私の質問は次のとおりです。

  • 同じテーブルのセットをクエリすると、パラメータごとにパフォーマンスが異なるのはなぜですか？
  • ここにはどのインデックスが関係していますか？
  • この単純なクエリやDBを改善して高速化する方法はありますか？

更新：サイズ感を与えるために：

Command> select count(*) from T_PROFILEGROUP;
< 183840 >
1 row found.

Command> select count(*) from T_PROFILECONTEXT_PROFILEGROUPS;
< 2279104 >
1 row found.
4

3 に答える 3

1

私は TimesTen に詳しくありませんが、他のリレーショナル DB と同じように機能すると仮定すると (メモリ内にあることを除いて)、考えられる理由の 1 つは、T_PROFILECONTEXT_PROFILEGROUP.M_ID_OID または T_PROFILEGROUP.M_ID 列にインデックスがないか、バイナリ ツリー インデックスがアンバランスになっていることです。 .

インデックスがない場合、検索結果はデー​​タの順序によって異なります。

大規模なデータを含むテーブルでは、ツリーの片側が他の側よりもはるかに大きいため、バイナリ ツリー インデックスのバランスが取れていないために問題が発生することがありました。このシナリオでは、インデックスを再構築することでツリーのバランスを取り直すことができます。

これが TimesTen を使用したことがなく、Web 検索であまり情報が得られない場合に当てはまるかどうかは正直に言えません。

于 2011-11-30T21:32:03.757 に答える
0

私の大まかな賭けは、最初のクエリがディスクまたは仮想メモリのいずれかから実際のメモリにデータをプルし、2番目のクエリがそれを利用することです。

これを3つ（または10つ）のクエリで実行して報告できますか？

于 2010-08-26T20:56:25.683 に答える
0

私は TimesTen データベースにあまり詳しくありませんが、ここでは 1/10 秒未満であるため、2 つのクエリの丸めの違いまたは何らかの問題でしょうか?

これは、TimesTen DB のパフォーマンス チューニングのいくつかの方法に関するリンクです。いくつかの一般的な情報 (prepare の使用など) と、特定のクエリのチューニングに関する情報が含まれています。お役に立てば幸いです。

于 2010-06-01T14:04:30.683 に答える