In-Memory OLTP 使用内存和磁盘的方式不同于传统的基于磁盘的表。 In-Memory OLTP 中看到的性能改进取决于你使用的硬件。 在本文中，我们将讨论几个常规硬件注意事项，并提供用于 In-Memory OLTP 的硬件的通用准则。
CPU
In-Memory OLTP 不需要高端服务器来支持高吞吐量 OLTP 工作负荷。 建议使用具有双 CPU 插槽的中端服务器。 由于 In-Memory OLTP 提升了吞吐量，两个插槽可能已足以满足您的业务需求。
建议在 In-Memory OLTP 中开启同时多线程处理 (SMT)。 使用 SMT 时，某些 OLTP 工作负载的性能提升高达 40%。
内存
所有内存优化表都完全驻留在内存中。 因此，对于表本身，必须有足够的物理内存，并维持针对数据库运行的工作负荷 - 实际需要的内存量实际上取决于工作负荷，但作为起点，需要足够的可用内存，以便大约两倍的数据大小。 如果工作负荷还需要处理传统的基于磁盘的表，那么需要为缓冲区预留足够的内存。
若要确定给定内存优化表使用的内存量，请运行以下查询：
select object_name(object_id), * from sys.dm_db_xtp_table_memory_stats;
结果显示内存优化表及其索引的内存使用情况。 表数据包括用户数据，以及运行事务仍需要的所有较旧行版本，或者尚未由系统清理。 哈希索引使用的内存是常量，不依赖于表中的行数。
使用 In-Memory OLTP 时，请务必记住整个数据库不需要容纳在内存中。 您可以拥有一个多TB的数据库，并且当热数据（即内存优化表）的大小不超过256 GB时，仍然可以从In-Memory OLTP中受益。 SQL Server 可为单个数据库管理的最大检查点数据文件数为 4,000，每个文件为 128 MB。 尽管这将提供 512 GB 的理论最大值，但为了保证 SQL Server 可以跟上合并检查点文件，并且不会达到 4,000 个文件的限制，我们最多支持 256 GB。 此限制仅适用于内存优化表;同一 SQL Server 数据库中基于磁盘的传统表没有此类大小限制。
非持久内存优化表（NDT），即具有 DURABILITY=SCHEMA_ONLY 的内存优化表不会保留在磁盘上。 尽管 NDT 不受检查点文件数的限制，但仅支持 256 GB。 此帖子其余部分中日志和数据驱动器的注意事项不适用于非持久表，因为数据仅存在于内存中。
日志驱动器
与内存优化表相关的日志记录将写入数据库事务日志，以及其他 SQL Server 日志记录。
将日志文件放在延迟较低的驱动器上始终很重要，这样事务就不需要等待太长，并且防止日志 I/O 上的争用。 系统的运行速度由最慢的组件决定（阿姆达尔定律）。 需要确保运行 In-Memory OLTP 时，日志 I/O 设备不会成为瓶颈。 我们建议使用低延迟的存储设备，至少使用 SSD。
内存优化表使用的日志带宽比基于磁盘的表少，因为它们不记录索引作，也不会记录 UNDO 记录。 这有助于缓解日志输入/输出争用。
数据驱动器
内存优化表的持久性使用检查点文件并通过流式 I/O 处理实现。 因此，这些文件不需要具有低延迟或快速随机 I/O 的驱动器。 相反，这些存储驱动器的主要因素是顺序 I/O 的速度和主机总线适配器（HBA）的带宽。 因此，不需要对检查点文件使用 SSD;只要其顺序 I/O 速度满足你的要求，就可以将它们放置在高性能轴上（例如 SAS）。
确定速度要求的最大因素是服务器重启时 RTO [恢复时间目标]。 在数据库恢复期间，内存优化表中的所有数据都需要从磁盘读取到内存中。 数据库恢复以 I/O 子系统的顺序读取速度进行;磁盘是瓶颈。
为了满足严格的 RTO 要求，建议通过将多个容器添加到MEMORY_OPTIMIZED_DATA文件组，将检查点文件分散到多个磁盘上。 SQL Server 支持从多个驱动器并行加载检查点文件 - 以驱动器的聚合速度进行恢复。
就磁盘容量而言，我们建议使用 2 到 3 倍的可用内存优化表的大小。
相关内容
- 用于 In-Memory OLTP 的示例数据库