SQL Server 记录行访问最佳实践

Question

我目前有一个文章数据库，它通过增加 page_load 上的“访问次数”计数器来跟踪一段时间内阅读次数最多的文章。当前的“访问”计数器是articles 表中的一列（见下文）：

id | title  | description | visits | creation_date
---+--------+-------------+--------+-----------------
1  | test1  | test test.. | 10     | 2019-01-01
2  | test2  | test test.. | 20     | 2019-01-01

有时，我遇到了连接超时，并且我怀疑“访问”写入过程会出现死锁（如果并发用户一次增加同一行，则会锁定数据库）。我认为下面的场景是一种增强：

1. 从表Articles 中删除Visits 计数器
2. 创建一个包含两列的新表article_visits：article_id 和date

文章

id | title | desc | creation_date
---+-------+------+---------------
1  | test1 | desd | 2019-01-01
2  | test1 | desd | 2019-01-01

article_visits

article_id | visit_date
-----------+----------------------
1          | 2019-01-01
1          | 2019-01-01
1          | 2019-01-01
1          | 2019-01-01
1          | 2019-01-01
1          | 2019-01-01
2          | 2019-01-01
2          | 2019-01-01
2          | 2019-01-01

作为替代选项，一旦触发新访问，我会在articles_visits 表中插入一个新行，以避免articles 表上的任何死锁。此解决方案将使articles_visits 表很快变大，但我认为表大小不是问题。

我想知道这是否是记录文章访问的正确方法，以及优化是否是比原始解决方案更好的选择。

Answer 1

这是记录文章访问的好方法。它更不容易（或根本不会）出现死锁，因为您基本上只是在追加新行。

它更灵活。例如，您可以获得两个日期之间的访问次数。这可以在查询时定义。您可以存储准确的时间，因此确定是否有视图的时间偏好。

缺点是查询性能。如果您经常需要计数，那么计算可能会很昂贵。

如果这是一个问题，有多种可能的方法：

• 定期汇总所有数据（例如数据）的过程。
• 一种基于该期间的期间汇总数据的过程（例如每日汇总）。
• 允许数据库保持数据最新的物化/索引视图。

Answer 2

这当然是有效的，尽管您可能希望对数据库服务器需要多少额外的存储和内存负载进行一些范围界定。

此外，我可能会为实际时间戳添加一个完整的 datetime 或 datetime2 列（除了当前日期列而不是它，因为您只想按日期进行聚合并拥有它value pre-computed 可以提高性能），也许还有一些其他的列，例如 IP Address 和 Referrer。然后您可以将这些数据用于其他目的，例如审核、跟踪引荐来源网址/广告客户的投资回报率等。

Answer 3

我很想知道您为什么会遇到死锁。应该是数据库平台应该能够同时处理update tablename set field = field + 1 就好了。此处表或行将锁定然后释放，但时间不应长到导致死锁错误。

如果您使用跨多个表的事务更新或锁定多个表，尤其是多个表，您可能会遇到死锁错误。如果您以不同的顺序执行它们。

所以问题是......在您的原始代码中，当您执行更新语句时，您是否链接到多个表？解决方案可能很简单，只需将更新原子化到一张表即可。

不过，我同意——你描述的表格是一个更实用的设计。

Answer 4

当前Articles 表不在Normalized form 中。

我会说将visits 列放在Articles 表中不是正确的方法 De-Normalization.

当前Articles 表不仅给您带来死锁问题，而且您无法获得这么多其他类型的报告。 Daily Visit Report, Weekly Visit Report.

创建Article_visits 表是非常好的举措。 它会非常频繁地更新。

我的Article_visits 设计

article_visit_id |   article_id | visit_date           | visit_count
-----------------+--------------+----------------------+----------------------
1                |    1         | 2019-01-01           | 6
2                |    2         | 2019-01-01           | 3

这里Article_Visit_id 是int identity(1,1) 也是Clustered Index。

Create NonClustered Index NCI_Articleid_date ON Article_visits(article_id,visit_date)
GO

简而言之，在article_id,visit_date 上创建 CI 会很昂贵。

如果该日期不存在该article 的记录，则插入visit_count 1 如果存在则更新visit_count，即增加1。

1. 已标准化。
2. 您可以创建任何类型的报告、当前需求 + 任何未来需求。
3. 您可以按文章计数显示。查询非常简单且高效。
4. 你可以得到周报，甚至得到年报都是如此简单，没有 Indexed View。

实际的表设计，

Create Table Article(Articleid int identity(1,1) primary key
,title varchar(100) not null,Descriptions varchar(max) not null
 ,CreationDate Datetime2(0))
    GO

 Create Table Article_Visit(Article_VisitID int identity(1,1) primary key,Articleid int not null ,Visit_Date datetime2(0) not null,Visit_Count int not null) 
    GO

--Create Trusted FK
    ALTER TABLE Article_Visit
    WITH NOCHECK
    ADD CONSTRAINT FK_Articleid FOREIGN KEY(Articleid) 
    REFERENCES Article(Articleid) NOT FOR REPLICATION;
    GO


    --Create NonClustered Index NCI_Articleid_Date on 
    -- Article_Visit(Articleid,Visit_Date)
    --Go

    Create NonClustered Index NCI_Articleid_Date1 on 
     Article_Visit(Visit_Date)include(Articleid)
    Go

创建 Trusted FK 以获得 Index Seek Benefit（简而言之）。 我认为，NCI_Articleid_Date 不再需要，因为Articleid 是Trusted FK。

Deadlock Issue: Trusted FK 也是为了克服死锁问题而创建的。 它经常由于糟糕的Application code 或UN-Optimized Sql query 或Bad Table Design 而发生。除此之外还有其他一些正当的原因，比如处理Race Condition。这是相当DBA 的事情。如果死锁伤害太大，那么在解决上述原因之后，您可能需要Isolation Level。

很多死锁问题都是由 Sql server 自己自动处理的。

DEADLOCK REASON网上有很多文章。

我不认为桌子大小是个问题

Table size 是大问题。两种设计中Deadlock 的机会非常非常少。但是您将始终面对Big Size 表中的其他demerit。

我告诉你再读几篇文章。

我希望这是您的完全相同的真实表，具有相同的数据类型？

两个表的插入/更新频率如何？

哪个表会被更频繁地查询？

同时使用每个表。

只能最小化死锁，以免出现性能问题或事务问题。

Visitorid 和 Artcileid 之间有什么关系？