0

我正在使用 Microsoft Sync Framework 2.1 将大量并发最终用户与中央数据库服务器同步。

环境：

  • 1500 个并发客户端连接到 1 个中央数据库服务器
  • Web 服务将用作服务器端 SyncProvider
  • 有多个表超过 2.000.000 条记录

问题
SelectChanges SP 经常超时 (CommandTimeout = 60)。
它可能很慢的原因：

  • Sync Framework 在 local_update_peer_timestamp 列上创建索引，但根本不使用它。
    • 即使在重新创建统计信息后，也不会使用索引
    • 索引提示会导致完整的索引扫描而不是查找操作（即使给定的时间戳远大于最大的 local_update_peer_timestamp 值）

问题 在我看来，事情正在变得非常糟糕。MS Sql Server 2008 R2 应该能够创建正确的执行计划

  • 如何改进选择更改？
    • 考虑到可以增长超过 8.000.000 条记录的表
    • 确保 SQL Server 使用索引来构建执行计划
  • 这个查询太慢还有其他潜在原因吗？
4

2 回答 2

1

上有一个CommandTimeout属性SqlSyncProvider，所以如果你不关心它需要多少时间，你可以通过将命令超时设置为超过最长的 selectchanges 查询所用的时间来解决这个问题。

我也注意到 selectchanges 存储过程的性能问题。SQL 在查询跟踪表方面似乎很慢。我怀疑这至少部分是内存压力，因为在正常操作期间您不会查询跟踪表。他们会有更新/插入，但我认为这些不会导致正确索引的正确部分加载到内存中。在没有正常操作发生的隔离环境中，selectchanges 过程要快得多。

您可以尝试将列添加到跟踪表（通过将它们添加到过滤器列的列表中）并设置自定义索引并修改存储过程以使用您的自定义索引。这样做我能够得到一些改进，但可能不足以证明所涉及的所有努力是合理的。

于 2012-04-16T16:12:38.623 回答
1

如果您使用过滤子句，则过滤条件进入 where 子句，这意味着 SQL Server 可能会选择对 select 中的每一行执行 where 子句，从而导致严重的性能问题。

在这种情况下，您可以创建自己的 selectchanges sproc 版本，它在连接中应用过滤条件，这将提高性能。

于 2014-03-07T19:02:22.460 回答