7

我注意到大约 150 万个输入值发生了一个有趣的性能变化。有人可以给我一个很好的解释为什么会这样吗？

表很简单。它由 (bigint, bigint, bigint, bool, varbinary(max)) 我在前三个 bigint 上有一个 pk 聚集索引。我只插入布尔值“true”作为数据 varbinary(max)。

从那时起，性能似乎相当稳定。

图例：Y（时间以毫秒为单位）| X（插入 10K）

在此处输入图像描述

我也对图表上的恒定相对较小（有时非常大）的峰值感到好奇。

峰值之前的实际执行计划。

峰值前的实际执行计划

图例：
我要插入的表： TSMDataTable
1. BigInt DataNodeID - fk
2. BigInt TS - 主时间戳
3. BigInt CTS - 修改时间戳
4. 位：ICT - 记录最后插入的值（提高读取性能）
5. 数据：数据
布尔值当前时间戳保持

环境
这是当地的。
它不共享任何资源。
它是固定大小的数据库（足够所以它不会扩展）。
（计算机，4 核，8GB，7200rps，Win 7）。
（Sql Server 2008 R2 DC，处理器关联（核心 1,2），3GB，）

4

1 回答 1

1

一旦时间到了，你检查过执行计划吗？该计划可能会根据统计数据而改变。由于您的数据快速增长，统计数据会发生变化，这可能会触发不同的执行计划。

嵌套循环适用于少量数据，但正如您所见，时间随着数据量的增加而增长。然后，SQL 查询优化器可能会切换到对大量数据保持一致的散列或合并计划。

要快速确认此理论，请尝试禁用统计信息自动更新并再次运行测试。那时你不应该看到“凹凸”。

编辑：由于 Falcon 确认性能因统计数据而发生变化，我们可以制定下一步。

我猜你会一一插入，对吗？在这种情况下（如果您不能批量插入），最好将其插入堆工作表中，然后定期将行批量移动到目标表中。这是因为对于每个插入的行，SQL 必须始终检查键重复、外键和其他检查以及排序和拆分页面。如果您有能力将这些检查推迟一段时间，我认为您将获得出色的插入性能。

我使用这种方法进行指标记录。日志将进入一个没有索引、没有外键、没有检查的普通堆表。每十分钟，我创建一个这种新表，然后在事务中使用两个“sp_rename”（快速交换），我使整个表可用于处理，新表进行日志记录。然后，您可以轻松地批量进行所有检查、排序和拆分。

除此之外，我不确定如何改善您的情况。您当然需要定期更新统计数据，因为这是获得良好性能的关键。

可能会尝试在这三列上使用单列标识聚集键和额外的唯一索引，但我怀疑它是否会有很大帮助。

可能会尝试填充索引 - 如果您插入的数据不是连续的。这将消除过多的页面拆分、洗牌和碎片。您需要定期维护填充物，这可能需要关闭时间。

可能会尝试给它一个硬件升级。您需要确定哪个组件是瓶颈。它可能是 CPU 或磁盘 - 在这种情况下我最喜欢。如果您有一张一张的插入，内存不太可能恕我直言。那么这应该很容易，如果不是 CPU（图表顶部的线），那么很可能是您的 IO 阻碍了您。尝试一些更好的控制器，更好的缓存和更快的磁盘......

于 2011-10-03T07:49:50.563 回答