小编Pix*_*ted的帖子

我们看到非常高的 PAGELATCH_EX 和 PAGELATCH_SH 等待类型以及高 WRITELOG 等待。我已经诊断出导致 PAGELATCH 等待的查询，并且可以通过降低插入到使用 IDENTITY 值定义的繁忙集群主键的插入率来消除它们。我知道这种现象被称为最后一页插入闩锁争用。

但是我的问题是，当插入新记录时，SQL Server 是否在缓冲页上取独占 PAGELATCH_EX，将记录​​插入缓冲页，将记录写入事务日志，然后按详细https://释放独占 PAGELATCH_EX www.microsoft.com/en-ie/download/details.aspx?id=26665 Page 24. 还是先将记录写入事务日志，然后再将 PAGELATCH_EX 作为详细的“Resolving PAGELATCH Contention on High Concurrent”INSERT Workloads -背景信息SQLCAT 的指南：关系引擎

如果记录是在闩锁机制之外写入日志，那么我可以排除由于高 PAGELATCH 等待而导致的缓慢写入磁盘的情况。但是，如果锁存器一直保持到记录被强化记录，那么我可能应该考虑 WRITELOG。

也有多个非聚集索引会导致 PAGELATCH_* 锁存器保持更长时间，即如果一个表有一个聚集和多个非聚集索引，同时向每个索引缓冲区页添加和释放锁存器？

更新 1 阅读confio-sql-server-writelog-wait幻灯片二和一般 WAL 架构后。我现在了解到，两份白皮书中详述的“记录该行已被修改的日志条目”步骤是指 SQL Server 记录事务日志缓存中的更改，而不是磁盘。一旦事务完成或缓冲区已满，所有记录都会立即刷新到磁盘。

阅读数据加载性能指南 后，我仍然不确定是否有必要将 TABLOCK 表提示添加到使用聚集索引定义的空临时表中，以便获得最少的日志记录。

显然，临时表是在 TempDB 中创建的，它在 SIMPLE 恢复模式下运行，所以我认为它是最小日志记录的完美候选者；然而，我找不到一段话来证实它。

临时表是否是最小日志记录的候选者，如果是，是否值得为永久表添加 TABLOCK 提示？

编辑：为什么会话报告被阻止但等待PAGELATCH_*，而不是LCK_M_相关的等待类型？

我之前假设 SQL Server 只会在 blocks_session_Id 列中报告阻塞会话。如果被阻塞的会话正在等待逻辑锁而不是其他任何东西，例如PAGELATCH_*.