MS Sync框架“枚举表xxxx的插入”突然变得极其缓慢。
与新信息编辑。
我继承了一个利用MSSyncFrame2.1与Server 2008 R2同步SQLServerCE3.5DB的项目。大约有一百万行，分布在十几张桌子上。其中两个表占行总数的75%。每天只有几十行变化，而且在这种轮辐和集线器安排中只有不到10个用户/安装。同步每天几乎没有什么工作要做，。
该项目的前一个版本可以在1-2分钟内完成“无所事事”同步(在两端插入、更新或删除零行)。因为我重新生成了.sdf (包括所有的数据)，所以现在至少需要9分钟，而对于某些用户来说则要长得多。
通过启用详细的同步日志记录，并将新的日志文件与旧的日志文件进行比较，我将问题缩小到了一种操作类型。所有额外的时间都记录为“枚举表xxxxx的插入”(客户端插入等待进入服务器)。更大的表比小的表花费更长的时间，但是对于这个操作，所有的表都按比例大幅增加，即使结果是零行。
编辑:显示在同步日志中的不受支持的查询语法(对于Server )的显然仅与服务器资源管理器查询窗口相结合无效。它在VS the编辑器中工作得很好。我现在已经比较了两个实际的查询计划。他们是一样的。从某种意义上说，这张大桌子被扫描一点也不奇怪。然而，在T编辑器中，对任何一个DB都需要相同的时间(~35秒)。显然，在该操作期间，同步引擎中正在进行更多的操作；尽管结果在所有情况下都为零行。
当我继承这个项目的时候，它已经进行了一半的小升级，但是我没有看到在源代码管理历史上有什么突出的地方。没有文档可以准确地描述以前的开发工作站设置。我已经将所有的表、列和索引与旧的.sdf进行了比较。新的.sdf和旧的.sdf大小相同。据我所知，没有新的库。我完全不知所措。
我在看什么？
回答 1
Stack Overflow用户
发布于 2015-09-04 15:45:48
虽然我从未了解为什么更新的文件在枚举要上传的本地更改时执行得比旧文件慢，但我想出了如何使它在这个场景中像它应该执行的那样执行(非常快)。
如前所述，框架在生成缓存时不创建任何索引。一些(实际上是大量的)实验显示，创建这个索引(在每个表上)似乎是最优的：
create index idx_ChangeTracking on yourTable (__sysChangeTxBsn, __sysTrackingContext, __sysInsertTxBsn);
枚举本地更改现在几乎是即时的，这本来就应该是这样的。为什么在生成表时这个索引不是由框架创建的，以及为什么以前它不重要(同样重要)？我想我们永远也不会知道。
https://stackoverflow.com/questions/31464925
复制相似问题
腾讯云开发者
