我在生产SQL 2005 DB上有一些需要架构更新的大表。这主要是添加了具有默认值的列，以及一些需要进行简单转换的列类型更改。整个过程可以通过简单的“SELECT INTO”来完成，其中目标是具有新模式的表。
到目前为止，我们的测试表明，即使这个完全在服务器内部完成的简单操作（不提取或推送任何数据），在数百万行的表上也可能需要数小时甚至数天。
此类表格是否有更好的更新策略？
编辑1：我们仍在试验没有明确的结论。如果我对新表的某个转换涉及将每五行合并为一个，会发生什么。有一些代码必须在每次转换时运行。我们可以获得的最佳性能让我们以至少几天的速度转换30M行表
在这种情况下使用SQLCLR（使用在服务器内部运行的代码进行转换）会给我一个主要的速度提升吗？
答案 0 :(得分：3)
您是立即应用索引还是在辅助步骤中应用索引？如果在构建期间没有索引，应该更快。
答案 1 :(得分：3)
您是否尝试过使用alter table而不是将数据移动到新表？为什么你会使用Select into？只是改变你目前的结构。
答案 2 :(得分：3)
我们遇到了类似的问题，我发现最快的方法是将数据导出到分隔文件（以块为单位 - 取决于行的大小 - 在我们的例子中，每个文件有500,000行） ，在导出期间执行任何转换，删除并使用新架构重新创建表，然后从文件执行bcp导入。
3000万行表使用该方法花了几个小时，其中alter table花了30多个小时。
答案 3 :(得分：0)
添加允许为null的列，然后手动更新为默认值，然后重新更改表以添加默认值。这样您就可以控制更新并以较小的块进行更新。
答案 4 :(得分：0)
我有类似的声音问题，这种问题经常发生。
我们的数据库缓存远程存储过程的结果，该过程偶尔会扩展为新字段。
这个表是数百万行（现在最多约80个字段），带有几个索引并且使用#temp表等（甚至使用bcp到临时文件）;我使用select into a new table选项：