sql-server-2008 - 批量插入 HEAP 与 CLUSTERED 索引，其中最小日志记录不是一个选项(SQL Server 2008)

Question

当前使用的工具是 Informatica，我们有 bookend 存储过程，可以删除聚集索引，然后将它们添加回数据库。在我们添加聚集索引的存储过程中，我们将索引的 DDL 硬编码到存储过程中(我们不使用 sys 表，因为担心 Microsoft 更改 sys 表并从那里重新生成会创建一个错误的索引或失败)。这会导致一些问题，即人们创建了聚集索引但没想到更新存储过程，并且下次批量发生时这些索引消失了。我们以前对所有索引都这样做过，但将非聚集索引切换为使用禁用/重建。但这不是一个选项，因为如果对聚集索引执行此操作，我们将不再能够插入到表中，因为它本质上是表。

性能很重要，但不是全部。良好的性能和易维护性胜过卓越的性能和复杂的可维护性。

在阅读了许多网站后，几乎普遍认为，在执行批量插入时，对与主键排序不同的数据，插入堆然后应用 pk 会更快(http://msdn.microsoft.com/en-us/library/ms177445.aspx
, http://msdn.microsoft.com/en-us/library/dd425070(v=sql.100).aspx )。大多数这些站点都做出了我无法在我的组织和我的工具集上使用的假设。

目前，由于我们当前的标准政策，我们必须使用完整恢复模型，因此无论我在引用堆还是聚集索引时做出哪个选择，都不会发生最低限度的日志记录。

根据我们的 informatica 管理员的说法，无法通过 UI 在 bcp 上指定 tabblock 或 order 提示，并且由于可维护性，我们的组织不利于 UI 之外的自定义。

因此，在所有这一切之后的问题是，考虑到上述所有因素，您是否建议我们继续使用我们有些不可靠的存储过程，插入聚集索引或使用第三种更好的解决方案。我也意识到还有其他与此项目类似的堆栈问题，但它们没有专门解决批量问题和/或在他们的答案中做出类似的假设。

Answer 1

我的建议是批量加载到一个临时表(一个堆，或者匹配文件顺序的 CI)，(重新)构建与目标表匹配的聚集索引，然后直接从临时表插入。为了减少阻塞、升级、日志使用等，您可以一次分批执行 10000 行，每隔一段时间提交和/或检查点。

您还可以考虑使用预处理器(可能是 C#)来获取日志文件并以正确的排序顺序构建一个新文件。

另外我认为使用 sys.indexes 等比在代码中硬编码索引结构更安全。 Microsoft 更改 sys.indexes 中的列名的可能性远低于您商店中的某个人(无意冒犯)更改索引但忘记更新过程中的硬编码定义的可能性。