是否需要定期压缩SQL CE数据库？汽车会缩水吗？我们的平均数据库大小约为100Mb，大型用户达到400-500Mb（但这些非常罕见）。如果我们必须手动压缩，我们如何判断应该何时应该？有没有办法以编程方式告诉碎片级别或浪费空间的百分比？如果没有，我们可以使用什么其他门槛？
该产品的早期版本是基于（ gasp ）MS Access数据库构建的，因此我们必须定期进行压缩以保持其正常工作。
答案 0 :(得分：8)
我想，如果您可以设置数据库以便根据需要自动缩小和修复，那就非常彻底了。这就是为什么缺乏关于最佳实践的文献;人们普遍认为它“只是有效”。因此，您在这方面获得的任何指导都将是模糊的。
以下是来自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的经验几乎没有相似之处。