甚至需要定期压缩 SQL CE 数据库吗？自动收缩就够了吗？我们的平均数据库大小约为 100Mb，大型用户达到 400-500Mb（但这种情况非常罕见）。如果我们必须手动压缩，我们如何知道什么时候应该压缩？有没有办法以编程方式告诉碎片级别或浪费空间的百分比？如果不是，我们还可以使用什么其他阈值？
该产品的先前版本是基于 (gasp) MS Access 数据库构建的，因此我们必须定期压缩以使其正常工作。
【问题讨论】：
标签： sql-server-ce
我想，如果您可以将数据库设置为根据需要自动缩小和修复，那将是非常彻底的。这就是为什么缺乏关于最佳实践的文献的原因。有一个普遍的假设是它“有效”。所以你在这方面得到的任何指导都是模糊的。
这是来自http://www.microsoft.com/web/library/Details.aspx?id=sql-server-2008-compact-express-depoly-manage 网络广播的（部分）引用
维护您的 SQL Server Express 版本与管理非常相似 任何其他多用户数据库，意思是 我们可以选择进去 处理文件组，我们可以处理 带有备份选项和恢复 模型和什么不是。 [但是]当我们交易时 使用精简版或 SQL 服务 CE，我们几乎没有那么多 选项。真的，我们唯一的选择 拥有是我们想要如何处理 收缩和修复。
这是另一个来自 MSDN 的 http://msdn.microsoft.com/en-us/library/ms838028.aspx#youcantakeitwithyou_sqlserverce_topic4
请注意，他们提供了有关数据库架构的详细信息，但仍然没有提供维护计划。他们的建议：在数据库开始变慢时执行此操作。 另请注意，此建议是在 2005 年左右，从那时起情况有所改善；即维护程序现已自动化。
保持您的房屋（或数据库）井然有序
SQL中大型数据库的性能 Server CE 2.0 是 数据库结构本身。身为你的 应用程序修改内容 数据库，记录变得更多 随机分布在 数据库文件结构。这个因素 尤其是在大 插入和删除的次数。到 确保对数据库的最佳访问， 之后压缩数据库 内容发生重大变化。除了恢复未使用的 空间，执行一个紧凑的 数据库有两个显着的影响 性能：首先，它存储所有 表记录按它们的顺序排列 首要的关键;其次，它更新 查询使用的统计信息 处理器。
按主键排序记录 可以显着提高主键 使用权。这是由于 SQL Server CE 面向页面的特性 （和大多数其他数据库）。相当 而不是从 数据库到内存，SQL Server CE 加载的记录块称为 页。当数据库记录 按主键顺序分组， 加载包含一条记录的页面 自动加载这些记录 相似的主键值。对于大多数 应用程序，这会导致什么 被称为良好的“命中率” 这意味着当您的应用程序 去访问连续的数据库 记录，很有可能 包含这些记录的页面 已经在内存中并且可以 直接访问。当记录 更随机分布，通常 大量发生后 插入和删除，有一个差 命中率要求 SQL Server CE 从数据库中检索更多页面 文件访问相同数量的 记录。
查询处理器统计信息 影响查询处理器的方式 确定最佳方法 定位记录。像这样的决定 是使用钥匙还是做 顺序扫描以定位特定 记录都受到查询的影响 处理器统计。作为 统计数据变得陈旧，有一个 查询的可能性增加 处理器可能会导致不太理想 决定。执行紧凑 刷新这些统计信息。
我很同情您使用 Access 数据库的经历。但是，我想您会发现您使用 SQL Server CE 的经验几乎没有什么相似之处。
【讨论】：