私は数百万行の顧客データを保持するデータベーステーブルを持っており、lastnameフィールドをNVARCHAR（32）からNVARCHAR（50）に変更する必要があります。フィールドにはインデックスがあります（クラスタ化されていません）。 ALTER TABLE ALTER COLUMN文でこの変更を行うと、自動的に索引が再構築されるかどうかを知る必要があります。SQL ServerのNVARCHAR列サイズを増やすとインデックスが再構築されるのですか？
もしそうなら、かなり時間がかかると思います。本番環境でのアップグレードプロセスは、スクリプトを実行するリリースされたインストーラを使用して実行され、アップグレードの所要時間を予測する必要があります。私たちはSQL 2005と2008の両方で大量のDBをプロダクションに持っているので、もしそれが違うなら、両方の答えを知る必要があります。
カラムのサイズを大きくすると、NVARCHARのような可変長フィールドのデータを変更すべきではなく、索引が含まれていない状況で大規模なデータセットであっても非常に速くなるはずです。私が明確にしていないのは、インデックスによってこれがはるかに遅くなるかどうかということです。
私は以下のリンクでドキュメントを読んでいますが、実際には既存のインデックスで変更できることを示し、ALTER TABLEステートメントの実行時間に与える影響は指定していません。
http://msdn.microsoft.com/en-us/library/ms190273.aspx
など、インデックスは後で再構築する必要がある、または自動的に行われているかどうかは、以下のリンクでの質問は、本当に私はここで聞いてるのよ、ほぼ同じものであるが、これには満足のいく答えはありません他の投稿、私は新しい投稿をしようと思った。
SQL Server 2005 Index rebuild when increasing the size of a varchar field
あなたはこの経験があった場合は私に知らせてください。私が実験できる大きさのDBを使ってテストシステムをセットアップすることができれば、結果を投稿します。
ありがとうございます！
あなたがしたすべてがサイズを増やしている場合は、インデックスを再構築する必要はないと思います。あなたがサイズを増やさずにテーブルの中で 'NULL'sを持っていて、*定義を' NOT NULL' *に変更して、古いサイズより大きい既定値を追加しない限り、行は変わらないので、インデックス内のデータは変更されません。しかし、あなたは確かにこれをテストすることができます* "大規模なDB"を作成せずに... –
大丈夫、クール。あなたが言及したもののどれも私の状況に適用されません。 NOT NULL NULL制約やDEFAULT値は、変更する必要がある列に定義されています。私は、文の実行時間が影響を受けるかどうかを確かめるために、単純なスクリプトを実装できるVARCHAR（50）列を持つ2つの表を作成することを検討します。あるテーブルにインデックスを付け、もう一方にはインデックスを付けることはできません。同じデータを持ち、唯一の違いがインデックスである場合、各テーブルの列をVARCHAR（100）に変更するのにかかる時間です。 – Jim
変更の前後にsys.dm_db_index_physical_statsを照会すると、重大な変更が行われた場合にも表示されることがあります。 –