私のSQL Serverデータベースに奇妙な問題があります。 SqlBulkCopy.WriteToServerを使用してバルクデータ（約90,000行）を書きました。また、EFのAddRangeを使用して、約30,000行を1,000バッチで書いています。バルク挿入時にインデックスが同期しなくなる
これにより、これらのテーブルのインデックスが同期しなくなり、クエリは通常よりも多くの時間がかかります（数秒後の結果ではなく10分後のタイムアウト）。
インデックスを手動で再構築した後、これらのインポートの別のものが発生するまで、クエリは再び高速になります。
バルクロードを理解すると、インデックスも更新する必要があります。 私の質問です：この動作はよく知られている理由はありますか？そうでない場合は、どうすればこの問題を起こすことができますか？
の統計を更新したい場合、私はどうかを把握しようとしました私は何とか20％の閾値を変えることができます。
そして実際、これを行う方法があり、あなたがこのようにそれを有効にすることができtrace flag 2371
を使用して：
DBCC TRACEON(2371, -1)
私は今、この問題を修正することを確認するために数週間待つことになるが、私はそれについて良い希望を持っています。
私たちは数年前と全く同じ問題を抱えています。そしてdfundakoが示唆したように、その答えは時代遅れの統計です。 SQLServerはデフォルトで、レコードの特定の割合が変更された場合に統計を更新します。テーブルに膨大な数のレコードがあると、90000レコードが変更された行の数の必要なパーセンテージに達しないという問題があります。 だからあなたは（あなたが行ったように）あなたのテーブルのインデックスを再作成のどちらか持って挿入した後、必ずや、ここでコメントや回答に基づいて、あなたのテーブル
update statistics <your table>
実際、問題の2つのテーブルには20,000,000と5,000,000の行があるため、各更新は20％のしきい値を大幅に下回ります。 –
私の2つの考えはテーブル/インデックスと多分フラグメンテーションに関する統計ですが、それほど多くの断片化はありません。 – dfundako
@dfundakoご意見ありがとうございます。このコメントを少し拡大できますか？私はそれを実際にタスク/次のステップに翻訳することはできません。ありがとう。 –
私はそれをよりよく説明できるよりもはるかに賢い人：https://www.simple-talk.com/sql/performance/sql-server-statistics-questions-we-were-too-shy-to-ask/ – dfundako