3

これが以前にここで尋ねられなかったことを願っています（私はここで検索し、グーグルで答えを探しましたが、答えが見つかりませんでした）

問題は次のとおりです。MS Access 2010 を使用して、リンクされたテーブルからレコードを選択しています (テーブルには数百万のレコードがあります)。条件 (日付など) を直接指定すると (date=#1/1/2013# など)、クエリはすぐに返されます。パラメーターを使用する場合 (日付/時刻型のパラメーターを追加し、プロンプトが表示されたときに 1/1/2013 の値を指定する (または別の形式の日付)、またはフォームでコントロールを参照する)、クエリの読み込みに数分かかります。

これを引き起こしている原因について何か考えがあれば教えてください。そのような質問をして、誰かの時間を無駄にする可能性があるのは申し訳ありません...

4

2 に答える 2

2

これが潜在的な答えです。私はこれを自分で知らなかったので、少し掘り下げました。

パフォーマンスが重要な場合は、クエリの最適化方法により、パラメーター クエリが適している場合でも、動的 SQL を優先する必要がある場合があります。通常、Access は保存時に新しいクエリのプランを作成します。クエリにパラメーターが含まれている場合、Access はパラメーターに含まれている可能性のある値を認識できないため、"適切な推測" を行う必要があります。後で提供される実際の値に応じて、正常または不十分な場合があり、最適なパフォーマンスが得られません。対照的に、動的 SQL はこれを回避します。これは、「パラメーター」が一時文字列にハードコードされているため、新しいプランがその値でコンパイルされ、最適な実行プランが保証されるためです。実行時に新しいプランをコンパイルするのは非常に高速であるため、動的 SQL がパラメーター クエリよりも優れている場合があります。

ソース: http://www.utteraccess.com/wiki/index.php/Parameter_Query#Performance

また、私が推測しなければならなかった場合、パラメータークエリで、Access は Oracle からテーブル全体を要求し、where 句でフィルタリングしますが、WHERE 句が指定されている場合、実際にはそれらのレコードをロードするだけで、インデックスを利用する可能性があります.

解決策としては、VBA でクエリ文字列を作成してから実行します。それは注射にあなたを開きますが、あなたはそれを処理することができます. そう：

Access で保存されたパラメーター クエリ オブジェクトを使用する代わりに、次のようなことを試してください。

 dim qr as string
 qr = "SELECT * FROM myTable WHERE myDate = #" & me.dateControl & "#;"

'CurrentDb.execute qr, dbFailOnError

  Docmd.RunSQL qr

または、あなたが答えたように、 currentdb.openrecordset(qr) これにより、最適ではない可能性のある計画を保存するのではなく、エンジンが実行時に実行計画を作成するようになります。これがうまくいくかどうか教えてください。興味があります。

于 2013-04-15T19:43:35.400 に答える