使用 Invantive Control（带有 Microsoft .NET 4.7 的 VSTO 插件）的复杂查询从 Exact Online 检索大约 200.000 行。这在 64 位版本的 Microsoft Excel 2010 及更高版本中运行良好。
在查询结束时进行强制 .NET 垃圾回收后，报告大约有 250 MB 的内存正在使用中。在此过程中，使用的内存会有所不同，但会出现 750 MB 内存的峰值。
但是，在 32 位版本上，用户在下载数据期间经常会遇到 OutOfMemory 异常。即使在重构查询以尽早删除未使用的列和行之后，它仍然不适合可用内存。
如何在 Excel 32 位版本中运行如此复杂的查询？
尽管至少从 Excel 2007 开始就可以使用 64 位版本的 Excel，但主要安装仍然是 32 位版本的 Microsoft Excel。
大多数加载项开发人员从未找到证明支持 64 位 Microsoft Office 的商业案例，并且在 2010 年左右的过程中，Microsoft 将使用 64 位版本的 Office 的建议更改为 32 位版本。
VSTO 加载项的可用内存因版本而异，但随着 Excel 本身复杂性的增加而减少。
目前，使用 1.75 GB 的可寻址内存空间，加载 Excel 和 .NET CLR，您最多可以为您的 .NET 代码和数据使用大约 250-300 MB。垃圾收集器在将它们全部放入可寻址内存空间方面做得很好，但这通常是不够的。
使用 64 位 Windows 版本（现在的通用版本）并为 Windows 添加更多物理或虚拟内存通常不会提高可用和可寻址内存的数量。这是 32 位地址空间设计的限制。
从 2016 年 5 月的版本开始，Microsoft 在 Excel.exe 的标头中设置了LARGEADDRESSAWARE位。这允许 32 位版本的 Excel 就像旧的 32 位版本的 Oracle 和其他版本一样，处理超过 2 GB 的内存。
知识库进一步记录了哪些版本提供了此功能。鉴于 Excel 2013 已停产，基本上您应该使用新版本的 32 位 Excel 2016 以避免出现 OutOfMemory 异常。
对于 Office365 订阅者，建议切换到包含足够新版本的 Excel 2016 的频道。
尽管对于 Excel，这会将可寻址内存空间增加到仅 3 GB，但它会将可用于您的 .NET 代码和数据作为 VSTO 的内存量从 250-300 MB 增加到 1250-1300 MB。可用内存空间增加了惊人的 4-5 倍。
Invantive Control 在帮助 -> 诊断窗口中显示可寻址的内存空间。
对于 Excel 的非 LARGEADDRESSAWARE 版本，它显示：
但对于 LARGEADDRESSAWARE 版本，它显示：
在分配超过 2 GB 的操作中：
