bud*_*ddy 2 performance sql-server index-tuning performance-tuning
我正在尝试确定为审计目的设计表格的最佳方式。基本上,我在一张表中为许多用户记录了几个最后的事件。每个用户的记录数有限制。新记录来了,旧记录走了。
像这样的东西:
CREATE TABLE Audit
(
UserId INT NOT NULL,
EventId INT NOT NULL,
CreationDate DATETIME NOT NULL,
UpdateDate DATETIME NULL,
-- Other data fields
)
Run Code Online (Sandbox Code Playgroud)
问题是如何处理索引。我正在考虑在(UserId, EventId)
. 但是由于用户活动是独立发生的,这意味着在表中间插入并在表中间删除。恐怕不好。
另一个想法是添加一个人工AuditId
字段只是为了让新记录的数量增加。像这样:
CREATE TABLE Audit
(
Id INT, -- Becomes the clustered index
-- The same as above
)
Run Code Online (Sandbox Code Playgroud)
这样,新的审计条目将被附加到末尾,但删除仍将发生在表的中间。它可能比第一个选项更好,但我不确定。
该表将被频繁使用,基本上每个用户活动都会被记录(1 次插入),并且最早的活动会在同一个事务中被删除(1 次删除)。这需要快速。好吧,我希望它在理想情况下是即时的,并且在性能方面不明显。
我还需要能够快速检索特定用户的记录集。它可能会被非聚集索引覆盖。
我正在寻求设计此表以获得最佳性能的建议。
编辑:我想我错过了一些重要的事情要提。
我试图追踪的不是瞬时的,而是一段时间内的。系统中有几个地方我需要这个。考虑用户正在做的某种活动可能会跨越某个时间段。如果满足某些条件,则重新使用(刷新、更新)现有活动。我只想删除旧的废弃活动。例如,在 2 周内,一个用户可能已经发布了 50 个活动,但对于另一个用户来说,产生的活动可能需要一年多的时间。这就是为什么我不希望所有用户一起使用一般有序的日志。
也不清楚我应该如何按日期时间进行聚类(如建议的那样)。我是在初始创建事件还是在更新事件上执行此操作?
通常,为了优化此类表的插入/删除,您将聚集在日期时间列上。(我想,您正在跟踪这些事件何时发生。)
这样,插入总是到表的末尾,最大限度地减少页面拆分的“坏”类型。删除或归档数据很容易,因为聚集索引将支持范围删除,并且这些操作通常不会锁定您正在执行插入的页面(除非您出于某种原因进行升级)。
您可能希望使用其他索引(如您所描述的索引)来支持查询,并且这些索引的维护当然会与 DML 有所干扰。
我不确定我是否理解为什么您只想为任何 UserId/EventId 组合保留一定数量的行。如果一个用户今天做了一大堆事情,你真的想删除他们昨天、上周等所做的所有事情,同时为不太活跃的用户保留旧数据吗?仅根据时间保留数据(例如保留两周的历史记录)不是更有意义吗?
我也不确定为什么删除绝对需要与插入耦合。删除不能推迟到后台进程而不是阻止插入事务吗?
归档时间: |
|
查看次数: |
2098 次 |
最近记录: |