2

SQL Server 2014介绍了一个看起来很棒的功能：In-Memory OLTP（In-Memory Optimization）。它让我想起了MySQL's MEMORY Storage Engine，我在几年前尝试过并获得了更好的性能。

我知道已经有人问过了，但我对更有针对性的场景感兴趣：

一些SSRS报告使用大型存储过程，出于性能原因（对于具有大量连接、分组等的查询，执行计划非常丑陋和缓慢），通过使用临时表来保存部分结果来拆分逻辑。

由于临时表是写入磁盘的，所以我预计在处理大量数据（数万甚至数十万行）时会对性能产生影响。

在这种情况下使用In-Memory OLTP tables有意义吗？我正在考虑以下优点和缺点。

优点：

  • 应该明显更快，因为所有数据都存储在内存中

缺点：

  • 需要明确的会话分离（表应包含某种会话标识符，以免混合来自各种SPIDs 的数据）
  • 需要明确的数据清理以避免内存不足（与退出声明范围后自动删除的临时表相反）
  • 需要注意表中存储的数据量
4

1 回答 1

2

你说对了。

但是请注意，临时表和任何其他表一样都是懒惰的（甚至比正常情况下更懒惰）。写入磁盘通常不在关键路径上，因为它是异步发生的。除了非常大的临时表会耗尽 SQL Server 将脏缓冲区保留在内存中的能力。

此外，如果临时表被快速释放，则根本不会有任何页面写入。

因此，您在此处列出的“专业人士”通常不会（完全）生效。

也就是说，即使在互操作模式下，内存表也倾向于使用更少的 CPU。所以“亲”总是至少有点真实。

您可以考虑使用仅模式的 Hekaton 表。这肯定不会导致任何数据写入。

于 2016-03-16T14:44:25.630 回答