我已经开始使用 QueryStore 来监控我的应用程序，我注意到的一件事是，对于我以为的简单操作，内存使用量却出乎意料地高：
这意味着每次执行该语句时都会使用近 600MB 的 RAM？
该时间范围内每次执行的 RowCount 都远小于 100。该语句本身每 5 秒运行一次。
该表已分区并基于列存储索引，没有其他索引或主键/标识，并且有大约 750k 行：
CREATE TABLE [DataLink].[LogEntry](
[AppInstanceId] [bigint] NOT NULL,
[LoggedOnUtc] [datetime2](7) NOT NULL,
[CategoryName] [nvarchar](256) NOT NULL,
[EventCode] [int] NOT NULL,
[EventName] [nvarchar](256) NULL,
[LogLevel] [int] NOT NULL,
[ScopeJson] [nvarchar](max) NULL,
[StateJson] [nvarchar](max) NULL,
[ExceptionJson] [nvarchar](max) NULL,
[Message] [nvarchar](max) NULL
) ON [PSCH_Logging_DataLink_LogEntry_Daily7Of9]([LoggedOnUtc])
CREATE CLUSTERED COLUMNSTORE INDEX [CIX_LogEntry]
ON [DataLink].[LogEntry] WITH (DROP_EXISTING = OFF, COMPRESSION_DELAY = 0, DATA_COMPRESSION = COLUMNSTORE)
ON [PSCH_Logging_DataLink_LogEntry_Daily7Of9]([LoggedOnUtc])
触发插入的代码：
using var conn = connInfo.Main.GetConnection(DatabaseLoginType.User);
await conn.OpenAsync(ct).CAf();
using var sqlBulkCopy = new SqlBulkCopy((SqlConnection)conn, SqlBulkCopyOptions.CheckConstraints | SqlBulkCopyOptions.FireTriggers, null);
foreach(var toWriteItemGroup in toWriteItems.GroupBy(x => x.SchemaName)) {
...
dataReader.Init(toWriteItemGroup, tableInfo.ColumnMappings.Length);
sqlBulkCopy.DestinationTableName = $"{schemaName}.LogEntry";
sqlBulkCopy.ColumnMappings.Clear();
for(int i = 0; i < tableInfo.ColumnMappings.Length; i++) sqlBulkCopy.ColumnMappings.Add(i, tableInfo.ColumnMappings[i]);
await sqlBulkCopy.WriteToServerAsync(dataReader, ct).CAf();
...
}
知道为什么内存使用率这么高以及我该怎么做才能解决这个问题？
编辑4
我通过更改和手动编译 Microsoft.Data.SqlClient 进行了一些测试。我所做的更改包括将 ROWS_PER_BATCH 和/或 KILOBYTES_PER_BATCH 添加到“insert bulk”语句的 with 选项中。所有选项都没有改变使用的内存量，但前者改变了行数估计：https://www.brentozar.com/pastetheplan/
?id=HkKjc9HIC 似乎无法针对低行数优化“insert bulk”。
编辑3
这是一个简短的示例，我可以通过它重现该问题。
它包含一个脚本“Script.sql”，需要先执行该脚本来设置表并添加一些数据。之后使用“dotnet run”运行该程序（或使用 IDE）。
由于我无法在此处上传文件，因此我已将其上传到 github gist：https://gist.github.com/DvdKhl/d042ed05e3237136265295cb39ecb4f4
该脚本将：
- 创建一个视图，显示表的 PartitionInfo
- 创建（或重新创建）表及其配置
- 插入 700k 行（每个分区 100k）
- 重建索引
- 输出分区信息
- 注释掉的是
- 事件会话（扩展事件）捕获查询计划
- 另一个插入语句
- 清理
该计划将：
- 在“localhost”上为数据库“main”打开一个连接
- 创建一个虚拟数据读取器（更改计数以更改插入的行数）
- 像上面一样设置 SqlBulkCopy
- 调用 WriteToServerAsync 插入行
这导致以下查询计划：https://www.brentozar.com/pastetheplan/? id=B1v_8bGLC
编辑2
按照 Denis Rubashkin 的建议我设置了 BatchSize 和顺序提示：
sqlBulkCopy.BatchSize = toWriteItemGroup.Count();
sqlBulkCopy.ColumnOrderHints.Add("LoggedOnUtc", SortOrder.Ascending);
BatchSize 似乎没有改变任何东西（估计值保持不变）。
看起来 ROWS_PER_BATCH 未被使用，尽管在代码中设置了 sqlBulkCopy.BatchSize，这可能是主要问题。
添加 Order 提示后，查询不会显示在 QueryStore 中。
但是使用扩展事件获取查询计划会显示“过度授权”警告。所以我不确定这是否有帮助。
KILOBYTES_PER_BATCH 选项看起来很有趣，但我似乎无法在 C# 代码中设置它。
WithOrderHint / WithoutOrderHint（不同的表，但问题完全相同）
编辑：
查询计划：https://www.brentozar.com/pastetheplan/? id=SJGpBktH0
表属性 - 存储
分区的磁盘使用情况
我做了一个测试
我创建了三张表
并
bcp在查看查询存储时针对其中 3 个运行了一个工具复制
我已将其作为 csv 文件存储在本地磁盘上
D:\OrderItems.csv并使用 PowerShell 在 5 秒循环中运行 bcp（将目标表更改为上述三个表之一）
后来我还添加了 LogEntry 表（尽管未分区），其中包含一些 chatGPT 生成的数据
结果
这些是来自查询存储的结果（不要介意每个开始时间的两行，那是因为时间段尚未关闭）
总结
我们可以看到，只有批量插入到列存储中才会产生较大的内存使用量。
LogEntry也具有比较大的使用量OrderItemCCX- 这可能基于数据大小或列存储段（更多列）。无论如何，每批插入 20 行对我来说并不是一项批量复制的工作。
我建议通读列存储索引 - 数据加载指南，并可能使用暂存表方法。
在附加的查询计划中，我看到的 Sort 运算符是唯一需要内存的运算符。对我来说奇怪的是，计划中声明的内存使用量为零：
也许服务器需要一些内存来处理来自您应用程序的二进制数据，或者这只是“插入批量”查询计划的一些功能。无论如何，我猜这么大的内存分配是因为远程扫描运算符中的错误估计（10000）。
您可以尝试添加提示
ROWS_PER_BATCH = rows_per_batch来改进估计，和/或添加提示ORDER LoggedOnUtc ASC以避免查询计划中的排序运算符。看看外部工具专用语法
希望这可以帮助。
批量插入针对批量插入进行了优化。对于聚集列存储目标，这尤其意味着内存授予的大小可以允许生成压缩行组，而压缩行组可能会占用大量内存。
您可能只打算插入少量行，并且可以说服优化器生成针对少量行优化的计划，但批量插入内存授予仍然会很大，因为在运行时可能会遇到大量行。
另一种看待这个问题的方式是，如果你只打算插入少量行，则不会使用批量插入。这是 SQL Server 做出的合理推断。
解决方法
尽管如此，
SqlBulkCopy从代码中使用确实很方便。如果你想要保持现有安排基本完好，但又想实现涓流插入，一种解决方法是使用触发器。现在，您不能直接在聚集列存储表上创建触发器，但可以在聚集列存储表的视图上创建触发器。
将触发器设为
INSTEAD OF插入触发器使我们能够将批量插入转换为涓流插入。例子
唯一需要更改的代码是：
您的演示代码将导致插入时没有内存授予：
严格来说，这是对隐藏临时表的插入。触发器执行的真正插入是：
这也具有零内存授予。
对于那些您拥有大量行并且想要执行批量插入的场合，请定位原始表名而不是视图（或省略
SqlBulkCopyOptions.FireTriggers）。