我们正在使用实体框架5代码优先的方法将MS Access数据库迁移到SQL Server Compact 4.0。我们发现，使用数据库生成的Integer ID非常慢，更糟糕的是，延迟随着数据库的大小呈指数级增加。这使得使用"标识"列成为不可能，而且在SQL Server Compact 4.0和实体框架中似乎有一个糟糕的此功能实现。
因此，我们进行了一些测试，发现使用客户端生成的密钥将操作插入速度提高了至少20倍，插入的指数增长消失了。
现在，我们正在寻找生成客户端ID的最佳方法。使用GUID似乎是最安全的选择，但我了解到这会对读取操作产生负面影响。使用客户端生成的自动递增整数有策略吗？
编辑：我将进一步调查导致这个问题的根本问题。与此同时，我真正的问题能得到回答吗？：-）
第2版：令人恼火的是，似乎没有人相信在EF和SQLServercompact4.0中使用auto-id的断言是如此缓慢。我发布了一个关于这一点的单独问题，并提供了一个易于复制的概念证明。
如果使用EF移动大量数据，则说明操作错误。请使用ADO.NET，例如使用BULK COPY方法（对于SQL CE，请使用SqlCeUpdateableRecord）。您可以使用我的SqlCeBulkCopy库来节省一些编码工作。
我不认为身份生成方式是性能问题的根源
我认为，如果您想在迁移过程中获得更好的性能，在转换过程之前，可以禁用主键和外键以及其他约束在你的主桌上。（这可以通过脚本或手动完成）
然而，数据完整性将是您新关心的问题，您的转换代码必须很强，这样在转换过程之后，启用约束就可以完成了
希望这能有所帮助
我所看到的解决方案。
a） 尝试修复性能问题。我的建议（不要在上下文中使用大量实体。）在业务问题允许的情况下尽量少用。不要使用合并跟踪等…请参阅EF性能提示。http://blogs.msdn.com/b/wriju/archive/2011/03/15/ado-net-entity-framework-performance-tips.aspx和http://msdn.microsoft.com/en-au/library/cc853327.aspx
b） 使用Guid。外部分配（不是顺序的，而是快速的）
c） 使用客户整数生成器，该生成器在内存中运行，可以一次分配多个键，并可以保持当前状态。SAP使用此技术。他们称之为"数字范围"。可以很快，但没有b）那么快。
顺便说一句，我使用GUID而不是数据库生成的ID来简化部分数据库复制和迁移。：-）