让我针对你的三个问题逐一拆解，结合你的场景（高INSERT频率、几乎无UPDATE、只读查询）来解答：

首先得搞懂背后的逻辑：你的只读查询默认会加共享锁（S锁），SQL Server本来倾向于用行级锁来减少对其他操作的影响，但当满足「锁升级」条件时，会把大量行/页级锁合并成表级S锁——这就是你观察到SELECT COUNT(Date)阻塞INSERT，但SELECT *不会的核心原因（表级S锁和INSERT需要的排他锁X锁冲突）。

锁升级的触发条件： #

• 单个事务持有的行/页级S锁数量超过5000个（这是默认阈值，可通过trace flag调整，但不建议随意修改）
• 数据库内存不足，无法维持大量细粒度锁

怎么判断当前查询的锁粒度？ #

1. 实时查询锁状态：用动态管理视图sys.dm_tran_locks查看，比如：

SELECT 
    resource_type, -- 锁的类型：OBJECT=表级，KEY=行级，PAGE=页级
    resource_object_id, -- 对应表的ID，可关联sys.objects查表名
    request_mode, -- 锁模式：S=共享锁
    request_session_id -- 发起锁的会话ID
FROM sys.dm_tran_locks
WHERE resource_database_id = DB_ID('你的数据库名')

如果resource_type是OBJECT，说明是表级锁；如果是KEY或PAGE，就是行/页级锁。

2. 看执行计划：

• 你的SELECT COUNT(Date)如果没有针对Date的非聚集索引，SQL Server会做全表扫描，扫描几亿行时会积累大量行级S锁，很容易触发锁升级到表级。
• 而SELECT *如果是带过滤条件的查询（或者有合适的聚集索引），锁的行数量没到阈值，就不会升级表锁。

3. 观察阻塞链：用SSMS的「活动监视器」查看阻塞情况，如果你的查询是阻塞INSERT的源头，且锁类型显示为表级，那就是触发了锁升级。

结合你说的「不在意历史数据或遗漏新增，但怕重复/损坏数据」的需求，两者的风险差异很大：

NOLOCK的核心风险： #

• 脏读：会读取到未提交的INSERT数据（如果INSERT事务回滚，你会读到根本不存在的数据）——不过你说不在意这个，暂时可以接受，但下面两个风险是硬伤：
• 重复读取/遗漏行：因为你的数据库INSERT频率极高，数据页经常会发生页分裂（新增数据导致页满，拆分出新页）。NOLOCK在扫描时，可能会把同一行读取两次（旧页和新页都扫到），或者完全跳过某些行。
• 损坏数据：极端情况下，当INSERT正在写入数据页时，NOLOCK可能读取到半写入的行（比如某些字段值不完整、NULL或者错误值）——这正是你最担心的严重问题。

READPAST的风险： #

• 遗漏锁定行：只会跳过被排他锁（X锁）锁定的行（比如正在执行INSERT的行），不会读取未提交的数据。你明确说不在意遗漏新增数据，所以这个风险对你来说完全可控。
• 没有重复读取或损坏数据的问题：它只读取已提交的、未被锁定的行，页分裂不会导致重复读，也不会读到半写入的不完整数据。

先给你列清楚核心差异：

针对你的担忧（重复/损坏数据），READPAST绝对是更安全的选择：

• 它完全规避了NOLOCK的致命问题（重复读、损坏数据），只会跳过正在被INSERT的临时锁定行——这正好符合你「不在意遗漏新增」的需求。
• 你的场景是数据几乎不更新，所以READPAST不会因为UPDATE的锁跳过数据，只会处理INSERT的临时锁，完美适配你的业务。

最后补充一个小建议：如果你的查询经常触发表级锁，除了用READPAST，还可以考虑优化执行计划——比如给COUNT(Date)加一个覆盖索引，这样查询只会扫描索引而不是全表，锁的粒度更小，从根源上减少锁升级和阻塞的概率。

内容的提问来源于stack exchange，提问作者Yakir Shlezinger