好吧，我知道这个愚蠢的问题，但是我看到了一个含糊不清的评论'一个大型数据库'以及中小型数据库，我想知道这意味着什么。有人可以为我们的SQL新手定义一个小型，中型和大型数据库吗？
答案 0 :(得分：95)
没有阈值，小型数据库变为中型或中型数据库变大。一般来说，当我听到这些术语时，我会考虑存储的总记录数量级。
正如海报 dkretz 建议的那样，您也可以根据每种数据库的属性来考虑它。用这种方式对它进行分类，我会说：
小：性能不是问题。您的查询运行正常，无需进行任何特殊优化。在使用索引等前端增强功能时，您只会看到边际性能差异。
中：您的数据库可能有一个或多个工作人员，他们被分配到其维护和保养的兼职。这些人关注数据库的健康状况;他们的主要管理职责是防止出现不可接受的性能问题，并尽量减少停机时间。
大：可能有专门的工作人员，他们的工作是处理数据库并提高性能，并确保应用程序更改不会导致数据库生命周期内的架构破坏。密切监视有关数据库的运行状况和状态的度量标准。理解和执行优化需要大量的专业知识。
非常大：数据库存储了大量必须易于访问的信息。绝对需要进行性能优化，以便从每个查询中获取最后一盎司的速度，如果没有它，数据库将无法使用甚至无法使用。数据库可能正在使用复杂或创新的复制或聚类技术，从而推动了当前技术的发展。
请注意，这些都是完全主观的，并且有人可能非常合理地使用“大”的替代定义。
答案 1 :(得分：27)
通过观察测试查询来确定它的一种方法。
小型数据库是索引无关紧要的数据库。
如果您没有适当的索引，则中型数据库是查询耗时超过一秒的数据库。
使用查询设计，索引修改和许多测试周期的组合，大型数据库的查询通常需要数小时才能进行优化。
答案 2 :(得分：4)
最佳答案，简介：大型数据库是迫使您不得不停止使用关系数据库的。
换句话说，一个规范化的关系型数据库，由于大量的JOIN，世界上所有索引都无法帮助您满足响应时间要求。
如果您不得不放弃关系数据库以获取其他内容，那么您可能是一个糟糕的数据库开发人员，没有专业的DBA，或者拥有一个非常大的数据库。
答案 3 :(得分：3)
“大型数据库”确实是一个模糊的概念。在这个问题的答案中已经发布了非常不同的答案和意见。定义“小”，“中”和“大”数据库的一些方法可能比其他方法更有意义但是在某些时候，我认为每个定义都是正确，真实和有效的。
某些定义比其他定义更有意义，因为它们侧重于数据库的设计，编程，使用，维护和管理的重要性的不同方面，这些不同的方面对于可用的数据库来说真正重要。恰巧所有这些方面都受到“数据库大小”模糊概念的影响。
那么，这是否意味着如果您能够定义特定数据库是否大而无关紧要？
当然不是。这意味着您将在评估数据库的不同设计/操作/管理方面时以不同方式应用该概念。这也意味着每次这个概念都是模糊不清的。
作为示例：数据库索引策略（数据库设计的一个方面）受每个表的记录计数（“大小”的度量），记录大小乘以记录计数（另一个“大小”度量）的影响，以及按查询比创建/更新/删除操作比率（数据库使用的一个方面）。
如果索引用于具有大量记录的表，则查询响应时间会更好。根据WHERE，ORDER BY和record-aggregation子句的性质，您可能需要为某些表提供多个索引。
创建，更新和删除操作会受到受影响的表上索引数量增加的负面影响。受影响的表的更多索引意味着RDBMS必须执行的更多更改，花费更多时间和更多资源来应用这些更改。
此外，如果您的RDBMS花费更多时间来应用这些更改，那么锁也会维护更长时间，从而影响同时向系统发送其他查询的响应时间。
那么，您如何平衡索引的数量和设计？你怎么知道你是否需要一个额外的索引，如果通过添加该索引，你不会对查询响应时间产生很大的负面影响？答案：根据您的负载/性能要求，针对目标负载测试和分析数据库，并分析分析数据，以发现是否需要进一步优化/重新设计/索引。
不同的查询对象需要不同的索引策略。创建/更新/删除操作比率。如果您的数据库负载很多，但很少更新，那么如果添加每个可以改善查询响应时间的索引，整个应用程序的性能会更好。另一方面，如果您的数据库不断更新但没有大型查询操作，那么如果使用较少的索引，性能会更好。
当然还有其他方面：数据库架构设计，存储策略，网络设计，备份策略，存储过程/触发器等。编程，应用程序编程（针对数据库）等等。所有这些方面都受到“大小”（记录大小，记录数，索引大小，索引计数，架构设计，存储大小等）的不同概念的不同影响。
我希望有更多时间，因为这个主题很吸引人。我希望这个小小的贡献可以作为你在这个迷人的SQL世界中的起点。
答案 4 :(得分：3)
您必须考虑此定义的硬件进展：
小型数据库：工作集适合单个商品服务器的物理RAM（现在大约16GB）
中型数据库：适用于单台机器上的单个或多个（通过RAID）商用硬盘（现在最多可达几TB）
大型数据库：数据需要分布在多个商品服务器上才能适应（现在最多可以容纳几个PB）。
答案 5 :(得分：2)
根据维基百科关于Very Large Database的文章
非常大的数据库（VLDB）是包含极大数量的元组（数据库行）的数据库，或者占用极大的物理文件系统存储空间。 VLDB最常见的定义是占用超过1 TB或包含数十亿行的数据库，但这种定义自然会随着时间而变化。
答案 6 :(得分：0)
我认为类似维基百科或美国人口普查数据是一个“大”数据库。我的个人地址列表或待办事项是一个小型数据库。中间数据库介于两者之间。
您可以尝试根据所需的服务器数量来定义大小。一个小型数据库是您在桌面上运行的应用程序的一个组件，一个中型数据库将是一个单独的mysql（无论）服务器，而一个大型数据库将需要多个具有某种复制/故障转移支持的服务器。
答案 7 :(得分：0)
如果你有一个足够大的数据库，你不能只是“备份它”来放置开发或测试盒，你可能有一个“大型数据库”。
答案 8 :(得分：0)
或者，将数据库的“大小”视为更改用于表示信息域的架构所需的时间。 （在实际实现中，数据库可能同时包含多个模式和不同的域。）
通过这种启发式方法，“大小”最终是存储信息的一个方面以及信息完全转换的速率。随着数据量/行数的增加以及技术和实现性能的提高，这种基于时间的方法也保持了一些类似“如何影响设计”的决策。