MS Access 数据库引擎表中的最大行数？答案

【问题标题】：Maximum number of rows in an MS Access database engine table?MS Access 数据库引擎表中的最大行数？
【发布时间】：2010-11-16 07:48:46
【问题描述】：

我们知道 MS Access 数据库引擎被“限制”以允许最大文件大小为 2GB（或者可能在内部被限制为小于 4KB 数据页的 2 个幂）。但这实际上意味着什么？

为了帮助我衡量这一点，您能告诉我可以插入到 MS Access 数据库引擎表中的最大行数吗？

为了满足表的定义，所有行都必须是唯一的，因此需要唯一的约束（例如PRIMARY KEY、UNIQUE、CHECK、数据宏等）。

编辑：我意识到有一个理论上的限制，但我感兴趣的是实际的（不一定可行），现实生活中的限制。

【问题讨论】：

可以插入重复的行来更新记录的 rpimary 键值。
@Ralph Rickenbach：谢谢，我没想到这一点（哦！）我已经编辑了这个问题，使一个独特的约束成为一个要求。
我认为说 Jet/ACE 被“节流”是不正确的，因为它可能在内部被限制为小于 2 的 4KB 数据页的某些功率（我没有得到尝试这个的任何漂亮的整数，所以那里一定有一些开销）。虽然更改可能不难，但它不符合 MS 更大产品线的利益，特别是考虑到他们确实在 4GB 上执行 THROTTLE SQL Server Express——我们知道它与完整的 SQL Server 引擎相同，但具有人工限制。

标签： ms-access jet ms-jet-ace

【解决方案1】：

一些cmets：

Jet/ACE 文件组织在数据页中，这意味着当您的记录边界未与数据页对齐时，会有一定量的松弛空间。
行级锁定将大大减少可能的记录数，因为它强制每个数据页一个记录。
在 Jet 4 中，数据页大小增加到 4KB（从 Jet 3.x 中的 2KB）。由于 Jet 4 是第一个支持 Unicode 的 Jet 版本，这意味着您可以存储 1GB 的双字节数据（即 1,000,000,000 个双字节字符），并且在打开 Unicode 压缩的情况下，可以存储 2GB 的数据。因此，记录的数量将受到您是否启用 Unicode 压缩的影响。
由于我们不知道 Jet/ACE 文件中有多少空间被标头和其他元数据占用，也不确切知道索引存储占用了多少空间，因此理论计算总是低于实用。
为了获得尽可能高效的存储，您可能希望使用代码而不是 Access UI 创建数据库，因为 Access 创建了纯 Jet 不需要的某些属性。这并不是说其中有很多，因为设置为 Access 默认值的属性通常根本没有设置（该属性仅在您将其从默认值更改时创建 - 这可以通过循环浏览字段的properties 集合，即 Access 表设计器中为字段列出的许多属性在 properties 集合中不存在，因为它们尚未设置），但您可能希望将自己限制为 Jet 特定的数据类型（超链接字段例如，仅限访问）。

我只是浪费了一个小时来处理这个问题，使用 Rnd() 填充定义为字节类型的 4 个字段，在这四个字段上使用复合 PK，并且需要永远附加足够的记录才能达到 2GB 的任何重要部分.该文件有超过 200 万条记录，小于 80MB。在达到 ~~700K~~ 700万 条记录并将文件压缩到 184MB 后，我终于退出了。接近 2GB 所需的时间比我愿意投资的要多！

【讨论】：

那么启动测试 MDB 的时间长度可能是因为索引复合键所花费的时间。我想知道使用自动数字键是否会快很多。
实际上，我很确定最后一批花了这么长时间的原因是因为要丢弃 9000 多个重复项（附加 200 万条记录）。我所做的是停止使用 Rnd() 并使用表作为源，只是交换列。当然，这确实导致了一些重复，我敢肯定这就是导致附加这些记录需要一个多小时的原因。
顺便说一句，我现在正在将其复制到一台较旧的 PC 上，以完成最多 2GB 的附加，以查看它有多少记录。这样我就可以让它运行而不会让我正在使用的机器陷入困境（昨天我运行它时它非常笨拙）。
只是一个更新：我现在有超过 1600 万条记录，文件刚刚超过 420MB。我正在开始另一轮附加随机数据。最后一批丢弃了 200 万个欺骗，所以我预计这一次会丢弃更多。
我要停下来过夜。该数据库现在有 2170 万条记录（最后一批中有 1100 万条记录被欺骗和拒绝），压缩后只有 600MB 以上。我生成唯一记录的方法显然不如以前有效，所以我想我现在就停下来。

【解决方案2】：

这是我的尝试：

我创建了一个没有键的单列 (INTEGER) 表：

CREATE TABLE a (a INTEGER NOT NULL);

从 1 开始依次插入整数。

当它插入 65,632,875 行时，我停止了它（在几个小时后任意）。文件大小为 1,029,772 KB。

我压缩了文件，将其略微减少到 1,029,704 KB。

我加了一个PK：

ALTER TABLE a ADD CONSTRAINT p PRIMARY KEY (a);

文件大小增加到 1,467,708 KB。

这表明最大值在 8000 万左右。

【讨论】：

【解决方案3】：

正如其他人所说，它是您的架构和索引数量的组合。

一位朋友在一个接近 2 Gb 限制的 MDB 中拥有大约 100,000,000 个历史股票价格（每日收盘价）。

他使用 Microsoft 知识库文章中的一些代码将它们拉下来。我很惊讶他使用的任何服务器都没有在前 10 万条记录后切断他。

他可以在一秒钟内查看任何记录。

【讨论】：

我想说，为了获得最大的空间，您还想用代码创建数据库，所以它是纯 Jet，没有任何不必要的 Access 特定功能。
@Tony Toews：这个问题是关于实际限制的。没有轶事，谢谢。
...但是指向该 Microsoft 知识库文章的链接可以让您获得一些代表 :)

【解决方案4】：

自从我上次使用 Access 以来已经有好几年了，但与较小的文件相比，较大的数据库文件总是存在更多问题并且更容易损坏。

除非数据库文件仅由一个人访问或存储在强大的网络上，否则您可能会在达到 2GB 数据库大小限制之前发现这是一个问题。

【讨论】：

-1 使用其他 SQL 产品无法帮助我找到 Access 数据库引擎表的实际限制。
我没有意识到我在评论中提倡使用另一种 SQL 产品？我指出，确定 Access 数据库大小的实际限制（无论这可能意味着什么）的一个重要因素是网络能够同时为多个用户提供大文件服务。
一个设计合理的前端应用程序不会为具有 100 万条记录的 Jet/ACE 后端检索任何数据，而不是具有 1000 条记录的后端应用程序，因为 Jet/ACE 检索的索引页为请求的数据集，然后只有存储这些记录的数据页。在任何一种情况下，这将是完全相同的数据量。只有在您进行全表扫描时（因为您是个白痴），您的场景才会相关。

【解决方案5】：

我们在这里谈论的不一定是理论上的限制，我们谈论的是最大文件大小和数据库架构的 2GB 的实际限制。

您的数据库是单个表还是多？
每个表有多少列？
有哪些数据类型？

架构在确定您可以拥有多少行时与行数保持一致。

我们已使用 Access MDB 存储 MS-SQL 数据的导出，以便我们的一些公司用户进行统计分析。在这些情况下，我们导出了我们的核心表结构，通常是四个具有 20 到 150 列的表，从每行 100 字节到每行 8000 字节不等。在这些情况下，我们会遇到几十万行数据是允许的 PER MDB 我们将发送它们。

所以，如果没有您的架构，我只是认为这个问题没有答案。

【讨论】：

我没有架构。挑战在于您想出一个模式，该模式将产生可能包含最多行的表（提示：我正在考虑一个唯一的单列表）。
行级锁定也有所不同，因为它强制每条记录使用一个数据页。
是的，答案将数以百万计，并且需要很长时间才能实现。如果以前没有人这样做，我会感到惊讶:)
这很令人困惑，我知道（请参阅我对问题的编辑！），但我的意思是“实用”的意思是“可以完成”，而不是“可行的”意思是“值得做”。但是，我认为了解实际限制是值得的，因为我怀疑它会表明实际限制超过了理论限制。有更清楚的吗？ :)

【解决方案6】：

这一切都取决于。理论上使用具有 4 字节数据类型的单列。您可以存储 300 000 行。但是即使在您做任何事情之前，数据库中也可能存在很多开销。我读过一些你可以有 1.000.000 行的地方，但同样，这一切都取决于..

您还可以将数据库链接在一起。将自己限制为仅磁盘空间。

【讨论】：

4 字节记录和 300K 行的数学运算根本没有加起来。我有长期生产使用的数据库，3 个表中有超过 300K 行（一个表有两倍），并且记录比单个 4 字节字段复杂得多。数据文件的大小大大小于 500MB（差不多一半）。
是的，你是对的。我错过了一些零。（2 GB）/（4 字节）= 536 870 912

【解决方案7】：

Practical = '在实践中很有用' - 所以你会得到最好的结果是轶事。其他一切都只是原型设计和测试结果。

我同意其他人的观点 - 确定“最大记录数量”完全取决于架构 - # 个表、# 个字段、# 个索引。

另一个轶事：我最近达到了 1.6GB 的文件大小，其中包含 2 个主要数据存储（表），分别为 36 个和 85 个字段，另外 3 个表中有一些子集副本。

谁在乎数据是否唯一——只有在上下文表明是唯一的情况下才是重要的。数据就是数据就是数据，除非重复会影响索引器的处理。

构成 1.6GB 的总行数为 1.72M。

【讨论】：

我要告诉你一个秘密：这只是一个有趣的挑战 :) 我所说的“实用”是指在实践中，而不是在理论上，所以轶事不是什么我正在寻找，谢谢。

【解决方案8】：

在处理 4 个大型 Db2 表时，我不仅发现了限制，而且让我看起来非常糟糕，因为老板认为我可以将所有四个表（每个表都有超过 900,000 行）附加到一个大表中。现实生活中的结果是，无论我尝试了多少次表格（它正好有 34 列 - 30 个文本和 3 个整数）都会吐出一些神秘的消息“无法打开数据库无法识别的格式或文件可能已损坏”。底线是少于 1,500,000 条记录，仅略多于 1,252,000 条，有 34 行。

【讨论】：