1

私たちのソフトウェアは、パフォーマンスの問題を抱えているクライアント サイトに展開されています。彼らは SQL コンサルタントを雇ってデータベースを調べ、ボトルネックがどこにあるかを確認しました。

コンサルタントが発見したことの 1 つは、多くのステートメントが に変換されていることでしたnvarchar。いくつかの調査の後、PreparedStatementそれを行っていたのは であることがわかりました。

例を挙げると：

PreparedStatement query = connection.prepareStatement("SELECT * FROM sys.tables WHERE"
        + " name LIKE ?");
query.setString(1, "%%");

なる

declare @p1 int
set @p1=1
exec sp_prepexec @p1 output,N'@P0 nvarchar(4000)',N'SELECT * FROM sys.tables WHERE name LIKE @P0        ',N'%%'
select @p1

一方、アドホックの executeQuery メソッドは、SQL を送信するだけです。

ResultSet rs = connection.createStatement().executeQuery("SELECT * FROM sys.tables WHERE  name LIKE '%%'");

になる

SELECT * FROM sys.tables WHERE  name LIKE '%%'

私が解決しようとしているのは、これが実際にどれほど悪いかということです。プリペアド ステートメントは、アドホック クエリよりも (複数回実行した場合) 効率的に使用できるため、アプリケーション全体で使用されます。

さらに、Microsoft の担当者が、パフォーマンスの問題を引き起こすことがわかっているものをドライバーに組み込むとは思えません。

これは本当に調査する必要があるものですか、それともコンサルタントは何もない問題を探していますか?

4

2 に答える 2

1

準備されたステートメントは、クエリをパラメーター化されたクエリにすることを強制します (これは良いことです) が、アドホック クエリは SQL エンジンによって自動パラメーター化される場合とされない場合があります。要するに、これは大きなパフォーマンス ヒットではありません。

ただし、設計の観点 (必ずしもパフォーマンスの観点からではありません) からパラメーター化されたストアド プロシージャを使用する必要があるかどうかについては、常に多くの議論があります。ほとんどの DBA (およびおそらくデータベース コンサルタント) は、従来のデータベース管理ツールを使用してデバッグしやすいため、ストアド プロシージャを好むと思います (また、セキュリティ上の利点があり、デフォルトでパラメーター化が含まれています)。

于 2012-06-29T17:17:36.410 に答える
0

プリペアド ステートメントにはアドホック クエリよりも多くの最適化オプションがあり、通常はセキュリティの観点から優れています (設計による SQL インジェクションはありません)。

nvarcharの使用は、通常、機能以外の要件に由来します。現在非常に一般的な Unicode 文字をアプリケーションでサポートする場合は、それが必要です。それが要件に含まれている場合は、変更しないでください。

LIKEクエリが原因だと思います。実際には、バックエンド データベースの全文インデックス作成機能を確認する必要があります。クエリは非常にシンプルに見えます。各フィールドの文字列をスキャンする LIKE '%' クエリです。

于 2014-09-06T06:47:23.340 に答える