Mysql SQL数据库：规范化与性能？

对于一个项目，我被要求查看一个现有的SQL数据库，看看它是否可以改进。它基本上是一个客户数据库，每个客户都有一堆不同类型的数据。这是（基本上）它的组织方式：

每个客户在customer表中都有一行客户ID。然后，对于每种类型的数据，每个客户都有自己的表。因此，例如，不会有一个用于“作业”的中心表，每行中都有一个客户ID，但对于每个客户，都会有一个名为“jobs1234”的作业表（1234是客户ID）

现在，我的第一个反应是对你为什么要这样组织它感到困惑。我一直都知道，在没有真正思考过这一点的情况下，正常化总是更好。但当我与人们讨论它时，一些人指出这可能是出于性能原因。他们说，如果“作业”的行太多，将它们按客户分开比将它们全部放在一张表中要好

---

关于索引和以客户ID作为标识符的问题。我不明白为什么这种方法会提高性能，到目前为止还没有得到一个非常明确的答案。有人能向我解释为什么会这样，以及这种方法在某些情况下是否真的更好吗？

我觉得这种说法相当令人震惊：

他们说，如果“工作”排得太多，那就太多了 与其将它们全部集中在一个客户身上，不如将它们按每个客户分开 桌子

数据库被设计成具有很多很多行的表——数百万行应该是没有问题的。您不指定数据量是多少，但是使用像

jobs

这样的名称，如果总的数据量超过几百万行，我会感到惊讶。对于这个数据量，应该使用一个具有适当索引的表好的

在某些情况下，按客户分割数据是有意义的。最强烈的情况是，这是一个明确的要求，通常是出于安全原因。换句话说，客户承诺“他们的数据永远不会与任何其他人的数据混合”。而且，在大多数数据库中（包括MySQL），在表级别处理安全性比在行级别更容易

另一个可能的原因是，表具有不同的格式，反映了每个客户的不同数据。在这种情况下，您实际上是在处理不同的应用程序，每个客户都应该有自己的数据库

将客户数据拆分为每个客户的多个表有什么不利之处吗？有。以下是一些：

您无法编写通用查询/视图来访问数据。基本上，代码中的所有查询都需要通过动态方式进行访问，以便输入正确的表名

维护数据变得很麻烦。要更新一个表，就必须更新多个表

回答诸如“每个客户有多少份工作？”或“随着时间的推移，工作数量的增长是什么？”之类的问题变得非常困难，以至于人们可能甚至不会费心去问他们

性能好坏参半。虽然您可能会节省在每个表中存储客户id的开销，但也会产生另一项成本。有许多较小的表意味着有许多表的页面部分填满。根据每个客户的作业数和总客户数，您实际上可能是在乘以空间量在最坏的情况下，每个客户一个作业，其中一个页面包含--比如--100个作业，您将需要的空间乘以大约100

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

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

---

除非有很好的理由将数据拆分为单独的表（这是一项要求，每个客户机都有繁琐的安全性，或者每个客户机都有自定义格式），否则您根本不会采用这种方法。即使有理由这样做，通常也会有其他解决方案（如分区）这就解决了同样的问题。

您所描述的与规范化无关。@MikeSherrill'Catcall'，也许我有点误解，但是：“数据库规范化是组织关系数据库的字段和表以最小化冗余和依赖性的过程”。这与这种情况不是有很大关系吗？如果你解释一下你所说的话的意思，而不是仅仅说它是“错的”，那会有所帮助。规范化涉及到列之间的某种依赖关系。你描述的是行之间的某种依赖关系。（所有行都在“jobs1234”中）属于客户1234。）其搜索词为“分区”所有当前的、主要的客户机/服务器DBMS都有本地的分区支持。我只会做一个自己动手的方法。我甚至会考虑换台来避免自己做。“McKeHelr''CATCALL’啊，为此欢呼。我还不知道这个术语。他伪造的模式，而不是现在的组织方式，如果它是这样出现的。（当时可能仍然是一个错误的词，但仍然）重组可以很好地解决这个问题。正常化被广泛误解。可能90%的关于正常化的问题与正常化无关。（90%的答案也是。）如果你不能识别一个规范化问题，你就不太可能正确地解决一个规范化问题。分区和索引问题也是如此。（这是一个观察者。）