我需要每天更新一个非常大的(300M记录)和广泛的TABLE1.更新的源数据位于另一个表UTABLE中,该表是TABLE1行的10％-25％但是很窄.两个表都将record_id作为主键.
目前,我正在使用以下方法重新创建TABLE1：
<!-- language: sql --> 1) SELECT (required columns) INTO TMP_TABLE1 FROM TABLE1 T join UTABLE U on T.record_id=U.record_id 2) DROP TABLE TABLE1 3) sp_rename 'TMP_TABLE1','TABLE1'
但是,我的服务器上需要将近40分钟(sql Server为60GB的RAM).我希望获得50％的性能提升 – 我可以尝试其他选项吗？
> MERGE和UPDATE – 类似下面的代码只适用于非常小的UTABLE表 – 在完整大小时,所有内容都会挂起：
<!-- language: sql --> MERGE TABLE1 as target USING UTABLE as source ON target.record_id = source.record_id WHEN MATCHED THEN UPDATE SET Target.columns=source.columns
>我听说我可以使用ROWCOUNT执行批量MERGE – 但我不认为它对于300M行表来说足够快.
>任何有用的SQL查询提示？
解决方法
实际上我已经找到了对这些查询的一般建议：使用sql Merge或Update的想法非常聪明,但是当我们需要在一个大而宽的表(即240M)中更新许多记录(即75M)时它失败了.
查看下面查询的查询计划,我们可以说TABLE1的TABLE SCAN和最终的MERGE占用了90％的时间.
MERGE TABLE1 as Target
USING UTABLE as source
ON Target.record_id = source.record_id
WHEN MATCHED AND (condition) THEN
UPDATE SET Target.columns=source.columns
因此,为了使用MERGE,我们需要：
>减少我们需要更新的行数,并将此信息正确传递给sql Server.这可以通过使UTABLE更小或指定缩小待合并部分的附加条件来完成.
>确保要合并的部分适合内存,否则查询运行速度会变慢.使TABLE1少两次将我的实际查询时间从11小时减少到40分钟.
正如Mark所说,你可以使用UPDATE语法并使用WHERE子句来缩小要合并的部分 – 这将得到相同的结果.另外,请避免索引TABLE1,因为这将导致在MERGE期间重建索引的额外工作
