当前使用的工具是 Informatica，我们有书端存储过程，可以删除聚集索引，然后将它们添加回数据库。在我们添加聚集索引的存储过程中，我们将索引的 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 或订单提示，并且由于可维护性，我们的组织不赞成在 UI 之外进行自定义。
因此，所有这一切之后的问题是上述所有因素，您是否会建议我们继续使用我们有些不可靠的存储过程，插入聚集索引或使用第三个更优越的解决方案。我也意识到还有其他类似于这个项目的堆栈问题，但他们没有专门解决批量问题和/或在他们的答案中做出类似的假设。