2

我有 160+ 百万条记录的 SQL Server 表，这些记录具有来自 UI、批处理作业等的连续 CRUD 操作，基本上来自多个来源

目前我已经在列上对表进行了分区，以便在表上获得更好的性能。

我遇到了 In-Memory 表，该表可用于频繁更新的表，并且如果从多个源发生更新，它不会加锁，而是会保持行版本控制，因此使用这种方法更好地进行并发更新。

那么在这种情况下我有什么选择呢？

分区表或创建内存表

正如我所读到的，当表被分区时，SQL 服务器不支持内存表。

在这种情况下，内存表或分区表有什么更好的选择。

4

1 回答 1

1

这取决于。

内存表在理论上看起来很棒，但您确实需要花时间学习细节才能做出正确的实现。你可能会发现一些令人不安的细节。例如：

如果您准备为使用 Hekaton 付出代价，您可以从阅读其白皮书开始。

分区本身有好处，但不能保证它会修复您的系统。只有特定的查询和案例场景才能从中受益。例如，如果 99% 的工作负载都在处理一个分区中的数据，您可能根本看不到任何优化。另一方面，如果您的报告基于历史数据并且您的插入/更新/删除触及另一个分区，那会更好。

这两种技术都很好，但需要仔细研究和仔细应用。通常，人们认为使用一些新技术可以解决他们的问题，而只要应用一些基本概念就可以解决问题。

例如，您说您正在执行超过 160+ 百万条记录的 CRUD。问你自己：

  • 我的表是否标准化 - 当数据以标准化方式存储时，您可以获得两件事 - 首先，您将仅对部分数据执行 CRUD，引擎可能只读取特定查询所需的数据（无需支持指数）
  • 我的 T-SQL 语句是否通过痛苦的行写得好，在循环中调用存储过程或不批量处理数据是慢查询的常见来源
  • 哪些是阻塞查询和死锁查询——例如，有可能一个长时间运行的查询阻塞所有插入——首先识别这些类型的问题并尝试通过数据预计算（索引视图）或创建覆盖索引来解决它们（也可以使用包含列进行过滤）
  • 读取器和写入器是否被阻止 - 您可以尝试不同的隔离级别来解决此类问题 - RCSI是 Azure 默认隔离级别。您可能需要向 TempDB 使用的 RAMDISK 添加更多 RAM，但由于您正在查看 Hekaton，因此与它（或分区）相比，这将更容易测试（和回滚）
于 2020-11-07T14:09:28.807 回答