mysql - SQL数据库: normalization vs.性能？

对于一个项目，我被要求查看现有的SQL数据库，并查看是否可以对其进行改进。基本上，这是一个客户数据库，每个客户都有大量不同类型的数据。这是(基本上)它的组织方式:

每个客户在客户表中都有一个带有客户ID的行。然后，对于每种数据类型，每个客户都有自己的表。因此，例如，将没有一个“工作”的中央表，每行都有一个客户ID，但是对于每个客户，将有一个名为“jobs1234”的工作表(1234是一个客户ID)。

现在，我的第一 react 是关于为什么要这样组织的困惑。我一直都知道，如果不真正思考超出这一点，进行标准化总是更好。但是，当我与人们讨论时，一些人指出这可能是出于性能原因。他们说，如果“工作”的行太多，那么将它们按客户分开要比将它们全部放在一个表中更好。

关于索引和客户ID是标识符的一些信息。我很困惑为什么这种方法可以提高性能，但到目前为止还没有得到一个非常明确的答案。谁能向我解释为什么会这样，如果在某些情况下这种方法更好甚至是真的？

最佳答案

我觉得这句话令人震惊:



数据库被设计为具有很多行的表-数百万行应该没问题。您没有指定数据量是多少，但是使用jobs这样的名称，如果总数据量总计超过几百万行，我会感到惊讶。对于此数据量，具有适当索引的单个表应该很好。

在某些情况下，按客户拆分数据很有意义。最有力的情况是它是一个明确的要求，通常是出于安全原因。换句话说，向客户保证“他们的数据绝不会与其他人的数据混合”。而且，在大多数数据库(包括MySQL)中，在表级别比在行级别更容易处理安全性。

另一个可能的原因是表格的格式不同，从而为每个客户反射(reflect)了不同的数据。在这种情况下，您实际上将处理单独的应用程序，并且每个客户都应该拥有自己的数据库。

将每个客户的客户数据分为多个表是否有不利影响？是的。这里有一些:

您不能编写通用查询/ View 来访问数据。基本上，代码中的所有查询都需要动态查询，因此您可以输入正确的表名。

维护数据变得很麻烦。如果要更新单个表，则必须更新多个表。

回答诸如“每个客户有多少份工作？”之类的问题。或“随着时间的推移，就业人数增长了多少？”变得难以回答，以至于人们甚至都不会问他们。

性能参差不齐。尽管您可以节省在每个表中存储客户ID的开销，但会产生另一笔费用。拥有许多较小的表意味着许多具有部分填充页面的表。根据每个客户的作业数量和整体客户的数量，您实际上可能会乘以所使用的空间量。在最糟糕的情况下，每个客户的一个页面包含一个工作-例如-100个工作，那么您将需要的空间乘以约100。

最后一点也适用于内存中的页面缓存。因此，当在许多表中拆分时，一个表中适合内存的数据可能不适合内存。

分区是实现类似功能的一种方法。但是，当查询负载一次集中在一个客户上时，这将是最好的方法。如果所有客户都在同一时间访问数据，那么分区将不会那么成功，而索引应该足够了。

除非有确凿的理由将数据分成单独的表(要求，每个客户端的繁琐安全性或每个客户端的自定义格式)，否则您根本不会采用这种方法。即使有这样做的理由，通常也可以使用其他解决方案(例如分区)来解决相同的问题。

关于mysql - SQL数据库: normalization vs.性能？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/17900645/