问到底什么是“大数据库”？

EN

一种方法是观察您的测试查询。

小型数据库是索引无关紧要的数据库。

中型数据库是指如果没有适当的索引，查询花费的时间超过一秒的数据库。

大型数据库通常需要几个小时才能优化查询，需要综合使用查询设计、索引修改和许多测试周期。

大型数据库会迫使您停止使用关系数据库。

换句话说，一个规范化的关系型数据库，由于大量的连接，世界上所有的索引都不能帮助您满足响应时间要求。

如果您曾经为了其他事情而不得不放弃关系数据库，那么您要么是一个糟糕的数据库开发人员，要么是没有专业的DBA，要么是拥有一个非常大的数据库。

“大型数据库”确实是一个模糊的概念。在这个问题的答案中已经有了非常不同的答案和观点。一些定义“小型”、“中型”和“大型”数据库的方法可能比其他方法更有意义，但在某种程度上，我认为每个定义都是正确的、真实的和有效的。

有些定义比其他定义更有意义，因为它们侧重于数据库设计、编程、使用、维护和管理的不同方面，而这些不同方面才是可用的数据库真正重要的方面。碰巧所有这些方面都受到“数据库大小”这个模糊概念的影响。

那么，这是否意味着你是否能够定义一个特定的数据库是否很大并不重要呢？

哪儿有的事儿。当然不是。这意味着在评估数据库的不同设计/操作/管理方面时，您将以不同的方式应用这一概念。这也意味着每次这个概念都将是模糊的。

例如:数据库索引策略(数据库设计的一个方面)受到每个表的记录计数(“大小”的度量)、记录大小乘以记录计数(“大小”的另一个度量)以及查询Vs的影响。创建/更新/删除操作比率(数据库使用情况的一个方面)。

如果索引用于具有大量记录的表，则查询响应时间会更快。根据WHERE、ORDER BY和record-aggregation子句的性质，您可能需要为某些表创建多个索引。

随着受影响表上索引数量的增加，创建、更新和删除操作会受到负面影响。受影响的表的索引越多，意味着RDBMS必须执行更多的更改，从而花费更多的时间和资源来应用这些更改。

此外，如果您的RDBMS花了更多的时间来应用这些更改，那么锁的维护时间也会更长，从而影响同时发送到系统的其他查询的响应时间。

那么，如何平衡索引的数量和设计呢？如何知道是否需要额外的索引，以及添加该索引是否不会对查询响应时间产生很大的负面影响？答:根据负载/性能要求，针对目标负载测试和分析数据库，并分析分析数据，以便发现是否需要进一步的优化/重新设计/索引。

不同的查询需要不同的索引策略。创建/更新/删除操作比率。如果数据库的查询负载很重，但很少更新，则如果添加每个索引来缩短查询响应时间，则整个应用程序的性能会更好。另一方面，如果您的数据库不断更新，但没有大型查询操作，那么如果使用较少的索引，性能会更好。

当然还有其他方面:数据库模式设计，存储策略，网络设计，备份策略，存储过程/触发器/等等。编程、应用程序编程(针对数据库)等。所有这些方面都受到不同的“大小”概念(记录大小、记录计数、索引大小、索引计数、模式设计、存储大小等)的不同影响。

我希望有更多的时间，因为这个话题很吸引人。我希望这篇小文章能为您在这个迷人的SQL世界中提供一个起点。