SQL Server - TRUNCATE TABLE 超过百万行后插入/选择速度很慢答案

【问题标题】：SQL Server - insert/select slow after TRUNCATE TABLE has 6 over million rowsSQL Server - TRUNCATE TABLE 超过百万行后插入/选择速度很慢
【发布时间】：2014-09-18 10:19:57
【问题描述】：

截断超过 600 万行的表后，插入/选择速度很慢。

我每天向表中插入 5 到 6 百万条记录，并且我能够在 7 或 8 天内毫无问题地插入/选择数据，但是当表大小超过 10 GB/3000 万行时，就会出现一些超时问题。

所以我想在上传数据之前每天截断表格，因为 1 天的数据对我来说已经足够了。现在我看到插入/选择非常缓慢，直到我在上传中间重建索引。过去 2 天，插入 100 万行需要 5 个小时，在重建索引后，剩余的 3.5 到 400 万行在不到 15 分钟的时间内进入表中。我不喜欢在上传过程中重建索引。

我不做 .NET Bulk insert ，我使用 Stored proc 批量插入行，因为我做了一些验证。

我使用的是 SQL Server 2008。

【问题讨论】：

这个问题很可能不是由于截断。截断后是否立即开始缓慢？持续多久？你如何定义“慢”？你是怎么测量的？
truncate后很慢，插入100万行花了将近5个小时。然后在重建索引之后，剩余的 450 万行在不到 15 分钟的时间内被插入。我不做 .NET Bulk insert ，我使用 Stored proc 批量插入行，因为我做了一些验证。
对不起，缓慢直到我重建索引。缓慢我的意思是插入记录的持续时间，通常（6 到 7 天）插入一批 80K 行需要不到 5 或 6 秒的时间，但是自从我开始截断同一批需要几分钟。在我重建索引后，一切都恢复正常。我不喜欢在上传过程中重建索引。
该信息很有帮助。一个不寻常的案例。没有明显问题。您是否启用了自动更新统计信息？服务器有多少内存？更新该表的统计信息但未重建索引后，该过程是否又快了？
否，自动更新统计未启用。我们有近 1TB 的内存，我们使用 SAN 磁盘。我没有尝试更新统计，因为它是生产数据库，等待批准。我们在测试环境中没有这个问题，它有 100GB 的内存。 5/6 百万行也消耗 1.7 到 1.8 GB 的内存。我们的数据库增长了 1GB。

标签： sql sql-server performance sql-server-2008 truncate

【解决方案1】：

启用自动统计更新后，一切正常。从现在开始截断大表后，如果禁用数据库自动统计更新，我将确保更新表统计信息。感谢大家提出的所有宝贵建议。

【讨论】：

【解决方案2】：

我建议你也删除索引，当你截断表时，一旦将数据加载到表中，然后继续创建索引，这至少会在一定程度上解决问题。

根据给定的信息，我不确定您使用什么实用程序将行加载到表中，

如果您使用的是 BCP，那么请将批处理大小设置为适当的值，因为单个事务中的 600 万条记录将创建一个非常大的事务，而不是您可以创建 50,000 的批处理大小，如果有任何批处理失败然后在再次加载之前截断整个表。

如需了解更多关于批量大小的信息，请转至浏览页面（-b 选项） http://msdn.microsoft.com/en-us/library/ms162802.aspx

【讨论】：

Surendra，我们不允许创建/删除索引。重建索引由 DBA 的计划任务完成。
当您说您从存储过程中批量插入行时，您使用的是简单的插入语句还是 BCP 或批量插入？
所有这些都是一般性的建议，没有解决他的具体问题。此外，这些都不能解释 20 倍的性能损失。

【解决方案3】：

确保更新所有索引的统计信息……而且缩小日志文件可能不会有什么坏处。网上都有关于如何做到这两点的文章。但这是我对正在发生的事情的最佳猜测。

【讨论】：

这并没有解决具体问题。这是非常一般的建议。我怀疑它是否适用
实际上，优化器对计划的错误估计会导致严重的性能问题。这当然是应该做的事情，或者至少应该考虑一下……鉴于原始问题中缺乏继续下去的信息。
我会添加一个注释，选择的答案正是我给出的答案，所以绝对没有理由两次投反对票。
当你给出这个答案时，没有任何线索统计数据会是问题所在。现在我们知道它们是问题所在，您需要说自动更新统计数据是问题所在，而不仅仅是一般的统计数据。此外，不知道缩小日志文件是否有助于解决此类问题。
实际上肯定有一个线索统计会是问题，这正是我回答我的方式的原因（我以前遇到过这个问题）。