问Server性能优化-审核表重新设计

EN

我认为您不需要改变太多，只需要重新设计您的流程，如下所示：

1. 创建一个与当前审计表完全相同的归档表。
2. 将所有当前可审计的内容转移到这个新的归档表中，这意味着当前的审核表为空。
3. 安排一项每天(或每周)的作业，以便将数据从审核表转移到归档表。
4. 根据您的数据保留策略，清理您的存档表。

但是对于性能问题，您必须确保插入到您的审计表中是否真的是罪魁祸首。如果是的话，那么上述的方法可以减轻你的痛苦.否则，可能于事无补。

我不得不做些类似的事。如果必须维护50亿条记录，那么最好的解决方案是对表进行分区。您需要执行以下操作：

1. 创建分区函数
2. 创建分区模式
3. 创建分区文件

分区函数将控制数据的分区方式:通常是按行数(即序列)或日期(即每月、季度、年度等)进行划分。注意:分区仅在SQLServer201XEnterprise上可用。

https://learn.microsoft.com/en-us/sql/relational-databases/partitions/partitioned-tables-and-indexes

我强烈建议您在做任何事情之前先阅读微软的白皮书。而且，一旦您实现了它，这应该在周末完成，以便进行处理，因为我认为这需要一些时间来完成。

https://technet.microsoft.com/en-us/library/dd578580(v=sql.100).aspx

为了进行比较，在预分区状态下运行10分钟后，查询将无法完成。对表进行分区后，查询将在10秒内完成。注意:一旦对表进行了分区，您将需要对查询进行调优，以便在谓词中包含分区列。否则，您可能不会注意到响应时间的差异。

您不太清楚性能问题在哪里:他们是在读表，还是在给表写信？通常情况下，如果问题是在读取表时，您会注意到系统中某个特定区域由于这样的读取而慢下来，而如果问题是写入表，则会产生更微妙的性能影响，但会更广泛，并且会使所有事情(在不同程度上)慢下来，而不仅仅是某些热点区域。

另一个不清楚的问题是，这主要是只写数据还是大量读取数据。审计表通常是经过写入优化的，以尽可能快的速度添加新数据，而在需要时则缓慢地从表中读取数据(通常，我们编写的比读取的要频繁得多:RDMS中的“正常”事务性行正好相反)。

因此，第一步是确定性能问题在哪里，并从其中收集一些线索，以确定您是需要优化表的读部分还是写部分。

如果这确实是一个写性能问题(与读取问题相比，更难描述和识别)，我可能会考虑删除一些表中的索引。我认为对于一个写优化的表，有很多索引在每个写操作上调用大量开销(请记住，每个索引都需要在每次对表的写操作中维护，所以当索引非常适合阅读时，它们会降低写入性能:特别是非聚集索引)。

如果这是一个阅读问题，我可能仍然选择写优化无论如何，然后设计一些方法，以改善阅读的性能，因为它是最好的，一旦它写优化。这里的其他答案特别说明了这一点，但是如果不更熟悉系统的需求，很难说哪个方向是最好的移动方向。