我们有配备 64GB 内存的 Windows Server 2019 Standard (x64)。
下面的截图显示内存使用率为 96%，SQL 服务器 Windows NT正在运行并使用 344.5 MB。
这是停止服务后的任务管理器SQL 服务器 Windows NT. 内存使用率下降至 8%。
我开始服务SQL 服务器 Windows NT再次。任务管理器非常低，只有 9%，但是 SQL Server 现在使用的内存比内存使用率为 96% 时更多。
两个问题：
- 内存出了什么问题？
- 如何在不重新启动 SQL 服务器实例的情况下降低内存使用量？
答案1
您在这里忽略了一个重要的细节：任务管理器显示 SQL Server 仅使用了 344.5 MB 的 RAM，但实际上它保留了更多（几乎全部）的 RAM 供自己使用。任务管理器不会显示这一点。任务管理器中的数字实际上加起来并不等于系统内存的 97%，因为那里没有显示保留内存。
您认为几乎所有内存都被其他东西用完了，因此 SQL Server 无法使用超过 344.5 MB 的内存，这种假设完全是错误的。它不是这样工作的。任务管理器可能会产生误导，请查看实际的性能计数器。
更新以尝试更好地解释它。
SQL 服务器通过设计将数据缓存在内存中，随着时间的推移，它将占用系统中几乎所有的可用内存；但是这些内存不会（或至少不会全部）显示在任务管理器中，因为 SQL Server 会尝试友好地运行，并告诉操作系统“我想要这么多内存，但它仅用于缓存，没有它我也能运行，所以如果您需要，请随时回收它”。这意味着任务管理器显示的 SQL Server 使用的内存比它实际保留的内存少很多。
这是绝不问题；这是故意为之。您看到的“问题”并不存在，只是您在任务管理器中看到的内容具有误导性。
如果您停止 SQL Server，它当然会释放所有分配的内存，包括任务管理器中显示的内存和未显示的内存（更多）。当您再次启动它时，它将使用很少的内存：随着 SQL Server 将数据加载到内存中并缓存数据，使用量将随着时间的推移再次增长。但这些内存中的大部分将再次不是在任务管理器中显示，因为该特定工具无法看到它。
我还要补充一点，如果 SQL Server需要内存，它会以不同的方式分配它，然后任务管理器会显示它；如果 SQL Server 确实使用了 60 GB 内存，你会看到它必需的那么多内存，而不是仅仅将其用于缓存。
答案2
您在这台机器上运行 SQL Server，因此它正在执行 SQL Server 所做的事情 - 它保留（几乎）所有操作系统上可用的内存，这样当它得到大查询或其他操作时，它不必分配 RAM，因为它已经拥有了。
您有几种选择。
- 接受它。如果您在这台机器上只运行 SQL Server，那么它就可以按预期运行。别管它。
- 限制它。如果您需要在此服务器上运行其他工作负载，则可以限制 SQL 将保留的 RAM 量。
除非 SQL 从未使用它所占用的 RAM，否则我绝对不会选择 2。只有在测量操作系统级 SQL 性能计数器和 SQL 级动态管理视图时，您才会知道这一点。
总体而言，您实际上试图解决什么问题？在这种情况下，“释放内存”是毫无意义的任务，除非您知道释放内存是为了其他用途。您是否遇到了 SQL 性能问题？如果是，您如何确定瓶颈在于 RAM，而不是索引设计不良或查询未优化等？
我要告诉你的是使用适当的监控来诊断性能问题。您需要对 SQL 和 Windows 有深入的了解才能做到这一点。如果您不是 DBA，请聘请一位或与一位 DBA 签订合同，或者如果这是购买产品的 SQL，请与您的软件供应商合作。如果这是贵公司自己编写的，没有 DBA，请聘请一位。
默认情况下，SQL Server 实例可能会随着时间的推移消耗服务器中大部分可用的 Windows 操作系统内存。一旦获取内存，除非检测到内存压力，否则不会释放内存。这是设计使然，并不表示 SQL Server 进程中存在内存泄漏。
/根据您的编辑进行编辑：
虽然我不是系统管理员，但在我看来，sql server 占用的内存很少，因为其他一切都被 Windows 占用了。
您几乎肯定错了。正如我上面提到的，SQL Server 会随着时间的推移分配几乎所有的系统 RAM。sqlserver.exe 进程使用的 RAM 量不会告诉您 SQL 实际分配了多少 RAM。DMV 和 perfcounters 会告诉您这一点。
我使用 SSMS 来处理数据库，我亲眼看到一切都很慢。即使是打开表格窗格查看所有表格等简单操作也要花一段时间，有时还会超时。
不要在 SQL 服务器上运行它，而是从您的工作站运行它。