我遇到了MS问题。访问。问题是，我当前的MS。访问后端文件大小为320 MB，但是在我压缩数据库后，它的文件大小仍然只有222 MB，这意味着我丢失了文件大小98 MB。我的问题是，那是什么问题？它丢失了98 MB的文件大小后，为什么为什么它在使用之前比以前更慢？那该文件中的记录丢失或没有丢失怎么办？预先谢谢你。
答案 0 :(得分：0)
这是正常现象，您没有丢失任何数据。压缩+修复（C + R）是您应该对数据库执行的常规维护。您进行这种维护的频率将在很大程度上取决于有多少用户，“搅动”了多少数据等。
因此有些可以持续数周甚至更长的时间，而无需使用C + R后端。一些，更少的时间。
那文件为什么会这样增长？
有多个原因，但是一个简单的原因就是允许多个用户，然后在删除记录时，访问无法回收磁盘空间，因为您（可能）有多个用户在处理数据。您不能将所有其他数据“向下移动”以填补“空缺”，因为那样会改变现有数据的位置。
因此，如果我正在编辑记录400，而另一个用户删除了记录200，则在200处存在一个“空洞”。但是，如果我要回收空间，则必须“向下移动”每个记录以填充那个洞。因此，如果数据库中有100,000条记录，而我删除了50条记录，那么现在我必须将MASSIVE 99950记录移回以填补该漏洞！那太慢了。
因此，代替处理99950条记录（大量数据）的庞大（缓慢）过程，然后仅需简单访问即可在该位置留下“漏洞”。
原因是多用户。假设有5位用户在系统上工作，那么当用户正在工作时，您就无法开始移动数据。因此，现有记录的位置或地点将一直在移动。
因此，要允许多个用户，移动记录是不现实的。
另一个导致文件增长的问题是，如果您打开并编辑记录（再次说位置，并记录100,000个中的50个）。如果您输入其他信息，现在该位置50处的记录过大，会发生什么情况？
所以现在您的记录太大了。现在，我们面临着删除的相反问题–我们需要扩大并扩大“空洞”或将50个斑点放大。为此，我们可能必须移动100,000个或更多记录才能增加该记录的空洞大小。
记录的“空洞”或“斑点”不再足够大。
因此，访问权限只是简单地将旧记录（旧点）标记并设置为已删除，然后访问将我们刚刚编辑的太大的记录放在文件末尾（因此在文件末尾展开） 。因此，即使只是进行编辑，文件也会增长，并且由于删除而不再是必需的。
因此，删除记录并不能真正“消除”漏洞，而且从性能的角度来看会减慢速度。
并且如前所述，如果我们移动记录（太慢了），那么处理数据的其他用户将发现他们正在处理的当前记录的位置不再位于同一位置。
因此，在编辑过程中，我们无法开始“移动”这些数据。
因此，访问操作期间无法收回空间。它太慢，会导致太多的磁盘I / O不能用于简单的删除，并且如上所述，当记录的位置由于某些删除而总是更改时，在多用户环境中也无法使用。
要收回所有这些“漏洞”和“斑点”，请执行C +R。因此，这是一种预定类型的维护，在没有人处理数据时进行。 （例如深夜，或所有工人回家后）。这也解释了为什么只有一个用户可以进行C + R的工作。
因此您不会丢失任何数据– C + R只是在回收未使用空间的所有“漏洞”和“斑点”，但是此过程非常耗时。
因此，在应用程序的“运行中”操作太慢，以至于无法重新占据这些位置。因此，这种对浪费和未使用空间的回收仅发生在C + R期间，而不发生在用户工作时的高速交互操作中。
我应该指出，“大多数”数据库系统都存在此问题，尽管“某些”尝试回收未使用的空间，但最好有一个单独的过程和单独的操作来回收系统中的该空间。维护，而不是在使用应用程序期间维护。
您所看到的是正常的。
在执行C + R之后，您应该会看到性能提高。通常不会很大，但是如果文件很大，到处都是空隙和空隙，那么C + R会大大减少文件大小，并有助于提高性能。 Access还可以重建索引，还可以按PK顺序对数据进行排序–当您“更频繁地”以PK顺序读取数据时，这也可以提高性能。