内存中 OLTP 垃圾回收
适用于： 
SQL Server Azure SQL 数据库 Azure SQL 托管实例
如果数据行已被一个不再活动的事务删除，则该数据行被视为是陈旧的。 可对陈旧的行进行垃圾回收。 下面是内存中 OLTP 中垃圾回收的特征：
不产生阻塞。 垃圾收集随着时间推移进行分布，对工作负荷的影响极小。
协作。 用户事务通过主垃圾收集线程参与垃圾收集。
高效。 用户事务将所使用的访问路径（索引）中的陈旧行解除链接。 这样会减少最终删除行时所需的工作。
快速响应。 内存压力会导致频繁垃圾收集。
可缩放。 提交后，用户事务执行部分垃圾收集工作。 事务活动越多，解除链接的陈旧行就越多。
垃圾收集由主垃圾收集线程控制。 主垃圾收集线程每分钟运行一次，或在提交的事务数目超过内部阈值时运行。 垃圾收集器的任务是：
标识已删除或更新一组行且在最旧的活动事务之前已提交的事务。
标识这些旧事务创建的行版本。
将旧行分组到每个单元有 16 行的一个或多个单元中。 执行此操作是为了将垃圾收集器的工作分配到若干较小的单元中。
将这些工作单元移到垃圾收集队列中，每个计划程序一个。 有关详细信息，请参考以下垃圾回收器 DMV：sys.dm_xtp_gc_stats (Transact-SQL)、sys.dm_db_xtp_gc_cycle_stats (Transact-SQL) 和 sys.dm_xtp_gc_queue_stats (Transact-SQL)。
在用户事务提交后，它识别与它在其上运行的计划程序相关联的所有排队项，然后释放内存。 如果计划程序上的垃圾收集队列为空，则它会搜索当前 NUMA 节点中的任何非空队列。 如果存在较少事务活动或者有内存压力，则主垃圾收集线程可访问任何队列的垃圾收集行。 如果在删除大量行后（举例）没有事务活动并且没有内存压力，则在事务活动恢复或有内存压力之前，不会对删除的行进行垃圾收集。