更新大型表的主表和子表的主键

你的想法应该奏效。第一种可能是我使用的方式。执行此操作时应注意的一些事项:
除非有当前备份,否则不要执行此操作。
我会把这两个值都留在主表中。这样,如果你必须从一些旧的文件中找出你需要访问的记录,你就可以做到。 执行此操作时,请将数据库取下来进行维护,并将其置于单用户模式。当您执行类似的操作时,最不需要做的就是当您处于流中时,用户试图进行更改。当然,在单用户模式下的第一个操作就是上面提到的备份。当使用量最轻时,您可能应该安排一段时间的停机时间。 先测试dev!这也应该让你知道你需要多长时间才能结束生产。此外,您还可以尝试几种方法来查看哪种方法最快。
请务必提前与用户沟通,数据库将在计划的维护时间和他们可以预期的时间停机。确保正时正常。当人们计划晚点运行季度报告,而数据库不可用且他们不知道时,这真的让人生气。
有相当多的记录,您可能希望批量运行子表的更新(不使用级联更新的一个原因)。这可能比尝试用一次更新更新500万条记录要快。但是,不要一次更新一个记录,否则明年您仍将在这里执行此任务。
删除所有表中guid字段的索引,然后在完成后重新创建。这将提高变更的性能。

创建一个新表,其中包含旧的和新的pk值。在两列上放置唯一的约束,以确保到目前为止没有破坏任何内容。

禁用约束。

对所有表运行更新,将旧值修改为新值。

启用pk,然后启用fk。

很难说出“最佳”或“最合适”的方法是什么,因为您没有描述您在解决方案中要寻找的内容。例如,当您迁移到新的ID时,这些表是否需要可用于查询?它们需要同时修改吗?尽快完成迁移很重要吗?将用于迁移的空间最小化是否重要?

说了这句话,我希望1比你的其他想法更好,假设它们都符合你的要求。

任何涉及到更新子表的触发器的操作似乎都很容易出错,并且过于复杂,可能无法执行1。

假设新的ID永远不会与旧的ID冲突是否安全?否则,基于一次更新一个ID的解决方案将不得不担心冲突——这会很快变得混乱。

你考虑过使用吗 CREATE TABLE AS SELECT (CTA)用新ID填充新表?您将复制现有表,这将需要额外的空间,但这可能比更新现有表更快。其思想是:(i)使用CTA创建新表,用新ID代替旧ID;(i i)在新表上创建适当的索引和约束;(i i i)删除旧表;(iv)将新表重命名为旧名称。

实际上,这取决于您的RDBMS。

使用Oracle,最简单的选择是使所有的外键约束“延迟”(检查提交),在单个事务中执行更新,然后提交。