在迁移项目期间,我面临着 SQL Server 中 400 万条记录的更新。
更新非常简单;需要将布尔字段设置为 true/1 并且我的输入是必须填写该字段的所有 id 的列表。(每行一个 id)
当涉及到这种大小的 sql 任务时,我并不完全是专家,所以我开始尝试 1 个包含“ WHERE xxx IN ( {list of ids, separated by comma} )
”的 UPDATE 语句。首先,我用一百万条记录进行了尝试。在测试服务器上的一个小数据集上,这就像一个魅力,但在生产环境中,这给出了一个错误。因此,我几次缩短了 id 列表的长度,但无济于事。
我尝试的下一件事是将列表中的每个 id 转换为 UPDATE 语句(“ UPDATE yyy SET booleanfield = 1 WHERE id = '{id}'
”)。某处,我读到每隔 x 行有一个 GO 很好,所以我每 100 行插入一个 GO(使用从 unix 移植的优秀的 'sed' 工具)。
因此,我将 400 万条更新语句列表分成 250.000 条,将它们保存为 sql 文件,然后开始将第一个语句加载并运行到 SQL Server Management Studio (2008) 中。请注意,我也尝试了 SQLCMD.exe,但令我惊讶的是,它的运行速度比 SQL Studio 慢了大约 10-20 倍。
完成大约需要 1.5 小时,并导致“查询完成但有错误”。但是,消息列表包含一个很好的列表,其中包含“1 行受影响”和“0 行受影响”,后者用于未找到 id 时。
接下来,我使用 COUNT(*) 检查了表中更新记录的数量,发现更新语句的数量和更新的记录数量之间存在几千条记录的差异。
然后我认为这可能是由于不存在的记录,但是当我在输出中减去“0 行受影响”的数量时,出现了 895 条记录的神秘差距。
我的问题:
有什么方法可以在“查询完成但出现错误”中找出错误的描述和原因。
895条记录的神秘差距如何解释?
进行此更新的更好或最好的方法是什么?(因为我开始认为我正在做的事情可能非常低效和/或容易出错)