Ms access Microsoft Access丢失了后端文件大小

我有Access女士的问题。问题是，我当前的MS.Access后端文件大小是320 MB，但在压缩数据库后，它的文件大小仍然只有222 MB，这意味着我丢失了98 MB的文件大小。我的问题是，那是什么问题？在它丢失文件大小98MB之后，为什么用户使用它时会比以前慢？那个文件中的记录是否丢失了呢？提前谢谢。

这是正常行为，您没有丢失任何数据。紧凑+修复（C+R）是您应该在数据库上执行的常规维护。您多久做一次这种维护将在很大程度上取决于有多少用户，有多少数据“搅动”等等

因此，有些可以持续数周，甚至更长时间，而不必对后端进行C+R。一些，更少的时间

那么为什么文件会像这样增长呢

有几个原因，但其中一个原因很简单，如果允许多个用户，那么当您删除记录时，access无法回收磁盘空间，因为您（可能）有多个用户处理数据。您不能将所有其他数据向下“移动”以填充“洞”，因为这会改变现有数据的位置

所以，如果我正在编辑记录400，而另一个用户删除了记录200，那么200处存在一个“洞”。然而，如果我想回收空间，我必须“向下移动”每一条记录来填补这个漏洞。因此，如果数据库有100000条记录，而我删除了50条记录，那么我现在必须将大量的99950条记录向下移动，以填补这一漏洞！那太慢了

因此，与处理99950条记录（大量数据）的庞大（且缓慢）过程不同的是，简单的访问将在该点留下“漏洞”

原因是多用户。假设有5个用户在系统上工作，那么您就不能在用户工作时开始移动数据。因此，现有记录的位置或地点将一直在移动

因此，如果要允许多个用户，则移动记录是不实际的

另一个导致文件增长的问题是，如果您打开并编辑记录（再次说位置和记录，100000中有50个）。如果你输入了额外的信息，而现在记录太大，不适合位置50的位置，会发生什么

所以现在你的记录太大了。现在，我们遇到了与删除相反的问题——我们需要扩展并使“洞”或spot 50变大。要做到这一点，我们可能需要移动100000条或更多的记录，以增加一条记录的洞大小

记录的“洞”或“点”已经不够大了

所以access所做的只是将旧记录（旧点）标记并设置为已删除，然后access将我们刚刚编辑的过大记录放在文件末尾（从而在文件末尾展开）。因此，即使只进行编辑，文件也会增长，而不仅仅是因为删除

因此，删除记录并不能真正“消除”漏洞，而且从性能的角度来看，这会降低速度

如前所述，如果我们移动记录（速度太慢），那么处理数据的其他用户将发现他们正在处理的当前记录的位置不再位于同一位置

所以我们不能在EDT期间开始“移动”数据

因此，access无法在运行期间重新占用空间。它速度太慢，导致简单删除时磁盘i/o太多，而且如上所述，当记录的位置总是由于某些删除而改变时，在多用户环境中也不起作用

要回收所有这些“洞”和“点”，则需要执行C+R。因此，这是一种计划维护类型，在没有人处理数据时执行。（比如说深夜，或者在所有工人回家后）。这也解释了为什么只有一个用户可以进行C+R

因此，您不会丢失任何数据–C+R只是重新声明所有未使用空间的“洞”和“点”，但这一过程非常耗时

所以，在应用程序的“运行”过程中，重新声明这些点的速度太慢。因此，这种对浪费和未使用空间的重新声明只在C+R期间发生，而不是在用户工作时的高速和交互式操作期间发生

我应该指出，“大多数”数据库系统都有这个问题，虽然“一些”试图重新声明未使用的空间，但最好在系统维护期间，而不是在应用程序使用期间，使用单独的过程和单独的操作来回收该空间

你所看到的是正常的

---

在C+R之后，您应该会看到性能的提高。通常不会太多，但如果文件非常大，充满了许多间隙和漏洞，那么C+R将大大减小文件大小，并有助于提高性能。Access还重新构建索引，并按主键顺序对数据进行排序–这还可以提高性能，因为您“更经常”以主键顺序读取数据。

如果从表中删除数据，则不会从数据库中删除数据，只是标记为已删除。它在Cpmpact上被删除（如果删除了大量数据，则应定期进行）。通常在那之后db会加速。为什么你的速度变慢应该还有其他原因。如果您想要一个可靠的后端，请使用类似于

sqlserver

等的东西。Compact就是这个意思。它将文件压缩到其净内容的大小，从临时表中删除剩余内容等。