0

約 200,000 レコードのデータベース テーブルがあります。これには、長さが 4000 ～ 70000 の文字列データを保持する 3 つの ntext 列が含まれます。ただし、テーブルで選択するだけで、データが返されるまでに 1 分以上かかります。where条件とインデックスを使用して、条件に対して12000レコードを選択しても、40秒かかります。

そのため、これらのデータ型を nvarchar(max) に変更することにしましたが、データが長すぎるために行の外に格納されるため、大きな違いはまだわかりませんでした。テーブルのこのパフォーマンスを向上させるより良い方法はありますか?

4

6 に答える 6

7

あなたの問題はフィールドのデータ型だと思いますか? 何よりも先に考慮すべき点が他にもいくつかあります。

  • テーブルにインデックスがありますか? それらを使用していますか？
  • 十分な帯域幅を利用できますか?
  • お使いの NIC カードは最新のドライバーを使用していますか?
  • クエリ実行計画を分析しましたか?
  • SQL サーバーに負荷がかかっていますか (CPU/メモリ/ディスク)? そしてあなたのウェブサーバー/デスクトップ？
  • データは正しく正規化されていますか?
于 2010-01-22T08:22:16.220 に答える
2

列を ntext ではなく nvarchar にする必要があり、それらを非キー列としてインデックスに含めることができます。しかし...それはあなたがフェッチしている大量のデータです。1 分間の実行時間が問題になるほど頻繁にクエリを実行する必要がある場合は、アプローチを再考する必要があります。

于 2010-01-22T12:08:30.790 に答える
1

私はケビンに同意します。スキャン (クラスター化インデックスまたはその他) はすべて悪いものであり、データを含めることは実際には実用的なオプションではありません。

テキストを独自の主キーを持つ別のテーブルに移動し、これら 3 つを元のテーブルの外部キーとして使用します。

私はこれと非常によく似た方法で、医療請求のテキスト データを保存しています。

(補足として) これのもう 1 つの利点は、返された結果セット全体に対して一度にこのテキストをすべて画面に表示する必要がないということです。そのため、特定のテキスト データのみをフェッチすることになります。あなたはすぐに必要です。

これにより、概要ビュー (stackoverflow で質問のリストを表示するようなもの) と詳細ビュー (単一のヘッダー レコードのすべてのテキスト データを表示するもの) の両方として同じテーブル構造を使用できます。

于 2010-01-22T12:21:49.480 に答える
1

ntext 列を別のテーブルに移動したくない場合は、最後のパスまでそれらの列を取得しないようにしてください。したがって、これの代わりに：

SELECT * FROM tbl WHERE (/* your code here*/)

次のようなことを試してください：

SELECT * FROM tbl WHERE id IN (SELECT id FROM tbl WHERE /* your code here */)
于 2010-01-22T23:12:55.293 に答える
1

大きなテキスト フィールドを別のテーブルに移動し、1 対 1 の関係でメイン テーブルにリンクすることはできませんか。それは物事をスピードアップするのに役立つかもしれません

于 2010-01-22T08:42:06.880 に答える
0

2 番目のクエリの場合、4.6 ギガバイトを超える転送が発生する可能性があるため、その時間がかかる可能性があることがわかります...

単一レコードのクエリの場合、固定長の列に分割してみることができます。

すなわち。part1 nchar(2000), part2 nchar(4000), part3 nchar(8000), part4 nchar(16000) ...

すべての列が変化しない場合、列がすべて固定長であると、行の境界を簡単に計算できます。

Query Analyze で「Show Execution Plan」を実行すると、何か役立つ情報が表示されます...?

于 2010-01-22T08:22:07.053 に答える