同步框架选择更改存储过程 - 性能/可扩展性/改进

我使用Microsoft同步框架2.1至大量的并发最终用户与中央数据库服务器同步。同步框架选择更改存储过程 - 性能/可扩展性/改进

环境：连接到1个中央数据库服务器

1500并发客户
一个web服务将被用作服务器端的SyncProvider
有超过2.000.000记录

问题
的SelectChanges SP regularl y用完时间（CommandTimeout = 60）。
之所以它可能是很慢：

同步框架上local_update_peer_timestamp列创建索引，但不使用它。
- 即使重建统计指标不使用
- 索引提示引起全索引扫描，而不是寻求操作（即使给定的时间戳比最大local_update_peer_timestamp值的方式更大）

后

问题在我看来有些事情是会非常糟糕。 MS Sql Server 2008 R2应该能够创建适当的执行计划

如何改进选择更改？
- 考虑到表可在8.000.000记录
- 增长确保SQL Server可使用索引来建立执行计划
是否还有其他可能的原因，为什么这个查询太慢？

来源

2012-04-16 hwcverwe

上有一个SqlSyncProvider财产CommandTimeout，所以如果你不关心它是如何花费的时间，你可以通过设置命令超时超过时间最长selectchanges查询需要的量解决这个问题。

我发现性能问题，存储过程以及该selectchanges。 SQL查询跟踪表似乎很慢。我怀疑这至少部分是内存压力，因为在正常运行期间，你将不会被查询跟踪表。他们将有更新/插入，但我不认为这些会导致正确的索引权部分获得加载到内存中。在没有正常操作发生的孤立环境中，selectchanges过程要快得多。

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

来源

2012-04-16 16:12:38 davidpricedev

感谢您的回答，我担心增加CommandTimeout作为最终解决方案。我已经做了这个临时解决方案，我想要一个真正的改进，但仍然感谢您的提示。关于过滤的列。谢谢我会尽力通过这样做来提高性能。如果我有一些改进，我会注意到你，如果你对我的解决方案感到好奇。谢谢！！ – hwcverwe 2012-04-16 16:50:36

如果您使用的是过滤器子句，那么过滤器标准将放在where子句中，这意味着SQL Server可能会选择对select中的每一行执行where子句，从而导致严重的性能问题。

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

来源

2014-03-07 19:02:22 lobo

同步框架选择更改存储过程 - 性能/可扩展性/改进

回答

相关问题