Sha*_*ehr 6 index sql-server-2008 sql-server
我正在维护别人的代码。有一个存储过程每天或每周运行一次（取决于配置），它将一堆记录从活动表迁移到存档。但它不是真正的存档，因为有几个实时进程在 SQL 查询中包含存档表，为此目的正确索引了存档表。
现在这个故事的历史是归档表越来越大，归档 SP 开始需要很长时间。所以有人决定在 SP 开始时删除存档表上的所有索引并在最后重新创建它们是一个好主意。当然，重新创建它们也需要很长时间，但可以说只要插入带有索引的新记录就行了。
这种情况只是对我尖叫：“这是罪恶的！ ” 在运行时搞乱索引似乎是错误的，错误的，错误的。我确信这不是一种罕见的情况，那么处理这种情况的“正确”方法是什么？
我认为答案的线索就在我问题的评论中：
但这不是真正的存档，因为有多个实时进程在 SQL 查询中包含存档表。
如果归档表被主动用于查询，那么它就不是归档，并且归档记录的全部意义已经丢失。
整个问题都归咎于错误的设计决策。最初，记录应该按一组完整的数据进行存档 - 在我们的领域中，这就是“订单”（如客户下的订单）。因此，当订单完成、付款且不再持续经营时，该订单及其所有相关数据都将被存档。然后有人出现并决定我们需要能够部分存档订单，因为有些订单中的一两个项目拖了几个月，但 99% 的订单已完成，因此他们希望将 99% 的订单推送到存档中。但为了获取与该订单相关的所有信息，您需要进入存档。因此，他们创建了一个跨实时表和存档表的视图，供车间应用程序使用。当然，一旦你这样做，你就违反了档案的概念，即它应该是你不需要定期查询的信息。一旦你做到了这一点，你不可避免地会开始走上这样的困境，这会极大地影响你的关键任务软件系统的性能。
因此，在这种特殊情况下，我将沿着修复最初的错误设计决策的路线，并停止这种部分存档的废话。然后，归档可以执行归档应该执行的操作（即坐下来享受退休生活），并让活动查询仅在活动表上运行。