具有大量数据的SQL Server内存表用例

我有一个 sql Server表，其中有160多个记录，这些记录具有来自UI，批处理作业等的连续CRUD操作，基本上来自多个来源

当前，我已将表划分为一列，以提高表的性能。

我遇到了内存中表，这些表可以用于频繁更新的表，并且如果从多个源进行更新，则不会加锁，而是会保持行版本控制，因此并发更新最好使用此表方法。

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

对表进行分区或创建内存表

我已经读过，对表进行分区时，sql Server不支持内存中表。

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

这取决于。

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

如果您准备为使用Hekaton付出代价，则可以先阅读其white-paper。

benefits附带了分区本身，但不能保证它将修复您的系统。只有特定的查询和案例方案可以从中受益。例如，如果您99％的工作量正在接触一个分区中的数据，那么您可能根本看不到任何优化。另一方面，如果您的报告基于历史数据，并且您的插入/更新/删除触摸另一个分区，那就更好了。

这两种技术都不错，但是需要详细检查并仔细应用。人们通常相信，只要应用一些基本概念就可以解决问题，那么使用一些新技术就可以解决他们的问题。

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

我的表是否已标准化-当以标准化方式存储数据时，您会获得两点好处-首先，您将仅对部分数据执行CRUD，引擎可能仅读取特定查询所需的数据（无需这样做）以支持索引）
我的T-SQL语句是否写得很好-row by agonizing row，循环调用存储过程或不批量处理数据是缓慢查询的常见原因
which are the blocking and deadlocked queries-例如，有一个长时间运行的查询可能会阻塞您的所有插入内容-首先确定这些类型的问题，然后尝试通过数据预先计算（indexed view）解决它们，或者创建覆盖索引（也可以使用包含列进行过滤）
是读写器被阻止了-您可以尝试使用不同的隔离级别来解决此类问题-RCSI是Azure默认隔离级别。您可能需要向TempDB使用的RAMDISK中添加更多RAM，但是由于您正在查看Hekaton，因此与它（或分区）相比，它更易于测试（和回滚）