为插入和删除优化审计表

Question

我正在尝试确定为审计目的设计表格的最佳方式。基本上，我在一张表中为许多用户记录了几个最后的事件。每个用户的记录数有限制。新记录来了，旧记录走了。

像这样的东西：

CREATE TABLE Audit
(
  UserId INT NOT NULL,
  EventId INT NOT NULL,
  CreationDate DATETIME NOT NULL,
  UpdateDate DATETIME NULL,
  -- Other data fields
)

问题是如何处理索引。我正在考虑在(UserId, EventId). 但是由于用户活动是独立发生的，这意味着在表中间插入并在表中间删除。恐怕不好。

另一个想法是添加一个人工AuditId字段只是为了让新记录的数量增加。像这样：

CREATE TABLE Audit
(
  Id INT, -- Becomes the clustered index
  -- The same as above
)

这样，新的审计条目将被附加到末尾，但删除仍将发生在表的中间。它可能比第一个选项更好，但我不确定。

该表将被频繁使用，基本上每个用户活动都会被记录（1 次插入），并且最早的活动会在同一个事务中被删除（1 次删除）。这需要快速。好吧，我希望它在理想情况下是即时的，并且在性能方面不明显。

我还需要能够快速检索特定用户的记录集。它可能会被非聚集索引覆盖。

我正在寻求设计此表以获得最佳性能的建议。

编辑：我想我错过了一些重要的事情要提。

我试图追踪的不是瞬时的，而是一段时间内的。系统中有几个地方我需要这个。考虑用户正在做的某种活动可能会跨越某个时间段。如果满足某些条件，则重新使用（刷新、更新）现有活动。我只想删除旧的废弃活动。例如，在 2 周内，一个用户可能已经发布了 50 个活动，但对于另一个用户来说，产生的活动可能需要一年多的时间。这就是为什么我不希望所有用户一起使用一般有序的日志。

也不清楚我应该如何按日期时间进行聚类（如建议的那样）。我是在初始创建事件还是在更新事件上执行此操作？

Answer 1

通常，为了优化此类表的插入/删除，您将聚集在日期时间列上。（我想，您正在跟踪这些事件何时发生。）

这样，插入总是到表的末尾，最大限度地减少页面拆分的“坏”类型。删除或归档数据很容易，因为聚集索引将支持范围删除，并且这些操作通常不会锁定您正在执行插入的页面（除非您出于某种原因进行升级）。

您可能希望使用其他索引（如您所描述的索引）来支持查询，并且这些索引的维护当然会与 DML 有所干扰。

我不确定我是否理解为什么您只想为任何 UserId/EventId 组合保留一定数量的行。如果一个用户今天做了一大堆事情，你真的想删除他们昨天、上周等所做的所有事情，同时为不太活跃的用户保留旧数据吗？仅根据时间保留数据（例如保留两周的历史记录）不是更有意义吗？

我也不确定为什么删除绝对需要与插入耦合。删除不能推迟到后台进程而不是阻止插入事务吗？