6

ResultSetExtractor 内で getInt を呼び出すとパフォーマンスの問題があります。GetInt は 20000 回呼び出されます。プロファイラー内での実行中、1 回の呼び出しのコストは 0.15 ミリ秒で、全体のコストは 24 秒です。SQL ステートメントの実行には約 8 秒かかります (主キー経由のアクセス)。私は mysql ドライバー バージョン 5.1.13、mysql サーバー 5.1.44、および spring-jdbc-3.1.1 を使用しています。パフォーマンスを改善するアイデアはありますか?

    mut.getMutEffect()[0]=(rs.getInt("leffect_a") != 0);
    mut.getMutEffect()[1]=(rs.getInt("leffect_c") != 0);
    ...
    mut.getMutEffect()[19]=(rs.getInt("leffect_y") != 0);
    mut.getMutReliability()[0]=rs.getInt("lreliability_a");
    ...
    mut.getMutReliability()[19]=rs.getInt("lreliability_y");

私のスキームは次のようになります

CREATE TABLE mutation (
 ...
 leffect_a BIT NOT NULL,
 lreliability_a TINYINT UNSIGNED NOT NULL,
 ...
 leffect_y BIT NOT NULL,
 lreliability_y TINYINT UNSIGNED NOT NULL,
 ...
) ENGINE=MyISAM;

編集: getInt 内でメソッド getIntWithOverflowCheck が呼び出されますが、これは高価なようです。このチェックをオフにすることは可能ですか?

4

2 に答える 2

2

以下にいくつかの提案を示します。

  • フェッチ サイズをかなり大きな数値に設定します: Statement.setFetchSize()。これにより、結果セットの処理中にデータベース サーバーへのラウンドトリップが削減されます。

  • プロファイリングによって select ステートメントが最適であることを確認する

  • 一般的なテーブルの最適化。たとえば、正しいデータ型を使用していますか? leffect_a を BOOLEAN に変更できるようです

  • SELECT ステートメントで不要な列を返していないことを確認してください。

  • PreparedStatementを使用する

  • スクロール可能で更新可能な結果セットを避ける (どちらもデフォルトではない)

于 2012-04-09T20:23:27.310 に答える
0

2 つの提案:

  1. getMutEffect()およびの結果はgetMutReliability()繰り返し使用されるため、ローカル変数に格納します。hotspot jit は重複する式をインライン化して削除する可能性がありますが、これに依存しない方が明確だと思います。
  2. 列名の代わりにインデックスを使用して ResultSet の値を取得する方が高速な場合があります。インデックスを作成する名前のローカル マップを作成することもできます。不思議なことに、一部の jdbc ドライバーでは、これは ResultSet にマッピングを行わせるよりも高速です。
于 2012-04-09T19:50:42.883 に答える