为了报告和历史目的而维护一个非常大的表的策略，在日常操作中使用了一小部分数据。
背景：
我们有访客和访问表，我们面向消费者的网站不断更新。这些表包含有关每次访问和访问者的信息，包括机器人和抓取工具，不会导致转化的直接流量等。
我们的后端站点允许从前端站点管理访问者（潜在客户）。大多数管理都发生在我们访客的一小部分（成为潜在客户的访客）上。访问者和访问表中的绝大多数数据仅用于更小的用户活动子集（基本上是报告类型功能）。这不是索引问题，我们已尽力完成索引并保持索引干净，小而且不碎片。
ps：我们目前没有数据仓库的预算或专业知识。
问题：
我们希望系统在查询时对我们的最终用户更敏感，例如，他们分配的潜在客户列表。目前，该查询针对的是大多数无关数据的庞大数据集。
我正在思考一些想法。一个涉及新表和一个相当重要的重新架构，我不是在寻求帮助。另一个涉及创建冗余数据（例如Visitor_Archive和Visitor_Small表），其中存在较大的访问者和访问表以用于插入和历史/报告，较小的visitor1表将用于管理潜在客户，发送带领电子邮件，需要潜在客户电话号码，需要我的潜在客户列表等。
我要联系的原因是我希望能够保持Visitor_Archive和Visitor_Small表保持同步的最佳方式......
复制？我是否可以使用复制仅复制具有特定列值的数据（FooID = x）
还有其他策略吗？
答案 0 :(得分：1)
听起来你的桌子是分区的理想选择。既然你没有提到它，我会简单描述一下，并给你一些链接，万一你不知道它。
您可以跨多个物理或逻辑设备划分表/索引的行，并且专门用于提高数据集的性能，您可能只需要在任何时候使用已知的数据子集。对表进行分区仍允许您将其作为一个表进行交互（您不需要在查询中引用分区或任何内容），但SQL Server能够对仅涉及数据的一个分区的查询执行多个优化。事实上，在Designing Partitions to Manage Subsets of Data中，AdventureWorks示例几乎与您的确切场景相匹配。
我会做一些研究，从这里开始并逐渐减少：Partitioned Tables and Indexes。
答案 1 :(得分：0)
简单的解决方案：创建单独的表，反规范化，包含其中的所有字段。创建存储过程，将根据您的计划更新此表。创建SQl代理作业以调用SP。
在您查看如何查询表时对其进行索引。
如果您需要清除历史记录，请创建另一个表来保存历史记录，并创建另一个SP来填充它并清理主报告表。
你最终可能会有多个报告表 - 没关系 - 这些天太空了。