我有一份长期工作。要处理的记录位于一个包含100K记录的表中。
现在，在查询此表的整个作业期间，它会查询这些100K记录。 处理完每个记录的状态后，对同一个表进行更新。
我想知道，如果我添加另一个表可以更新记录状态会更好，并且在此表中继续删除处理的任何记录，以便查询继续执行no。主表中的记录将减少查询性能。
编辑：主表基本上仅用于此加载。我收到一个平面文件，我在处理前上传它。在对此表进行验证后，我一次选择一条记录并将数据移动到适当的系统表。
答案 0 :(得分：3)
我遇到了类似的性能问题，其中一个表通常有几百万行，但我只需要处理自上次执行开始以来发生的变化。在我的目标表中，我有一个IDENTITY列，所以当我的批处理开始时，我从我选择的ID中获得最高IDENTITY值，其中ID大于我之前的批处理执行。然后，在成功完成批处理作业后，我将一条记录添加到一个单独的表中，该表指示已成功处理的最高IDENTITY值，并将其用作下一个批处理调用的开始输入。 （我还要补充一点，我的书签表是通用的，所以我有多个不同的工作，每个工作都有唯一的工作名称。）
如果您遇到锁定问题，因为每个记录的处理时间需要很长时间，您可以使用我上面使用的方法，但将您的集合分成1,000行（或者系统可以及时处理的任何行块大小）因此，您只能在任何给定时间锁定较小的集合。
答案 1 :(得分：1)
几个指针（我的两分钱）：
根据“系统表”目的地，考虑将该表与“缓慢变化的维度”技术分成几个“中间”表。然后批量加载系统表 - 而不是按记录记录。
在批量加载之前删除“input”表，并重新创建以删除索引等
在加载之前，不要在该表上分配不必要的（键）索引。
考虑将数据库“恢复模式”切换到批量加载模式，而不是记录批量事务。
您可以使用SSIS（ETL）任务进行加载，清理和验证吗？
<强>更新
这是一个典型的ETL场景 - 好吧，取决于你与谁交谈
的 1 即可。 提取到flat_file_1（你有）
的 2 即可。 清洁 flat_file_1 --> SSIS --> flat_file_2（您可以在此处验证）
<强> 3 即可。 符合 flat_file_2 --> SSIS --> flat_file_3（适用所有公司标准）
的 4 即可。 发送 flat_file_3 --> SSIS (bulk) --> db.ETL.StagingTables（几个，每个目的地一个）
的 4B 即可。 insert into destination_table select * from db.ETL.StagingTable（批量加载您的最终目的地）
这样，如果进程（1-4）超时，您始终可以从中间文件开始。您还可以检查每个阶段并从SSIS为每个阶段创建报告文件，以控制数据质量。操作1-3本质上很慢;这里它们发生在数据库之外，可以在单独的服务器上完成。如果归档flat_file(1-3)，您还可以对正在进行的操作进行审计跟踪 - 也适用于调试。 ：）