数据库速度优化：少表多行，还是多表少行？答案

【问题标题】：Database speed optimization: few tables with many rows, or many tables with few rows?数据库速度优化：少表多行，还是多表少行？
【发布时间】：2010-10-26 05:15:30
【问题描述】：

我有一个很大的疑问。

让我们以任何公司订单的数据库为例。

假设这家公司每月大约有 2000 个订单，因此，每年大约有 24,000 个订单，他们不想删除任何订单，即使它已经 5 年了（嘿，这是一个例子，数字不要'没有任何意义）。

就数据库查询速度而言，最好只有一张表，还是每年一张表会更快？

我的想法是每年为订单创建一个新表，调用此类 orders_2008、orders_2009 等。

加快数据库查询是个好主意吗？

通常使用的是当年的数据，所以行越少越好。显然，当我同时在所有订单表中搜索时，这会出现问题，因为我应该运行一些复杂的 UNION .. 但这种情况在正常活动中非常罕见。

我认为最好有一个应用程序 95% 的查询是快速的，而其余的则有点慢，而不是一个总是很慢的应用程序。

我的实际数据库有 130 个表，我的应用程序的新版本应该有大约 200-220 个表。其中大约 40% 将每年复制一次。

有什么建议吗？

编辑：RDBMS 可能是 Postgresql，可能（希望不是）Mysql

【问题讨论】：

标签： performance postgresql database-design

【解决方案1】：

较小的表更快。期间。

如果您有很少使用的历史记录，那么将历史记录到其他表中会更快。

这就是数据仓库的意义——将运营数据与历史数据分开。

您可以运行从操作和负载到历史的定期提取。所有数据都被保留，只是被隔离了。

【讨论】：

【解决方案2】：

在担心查询速度之前，请考虑成本。

如果您将代码拆分为单独的代码，则必须有代码来处理它。你写的每一段代码都有可能出错。您要求您的代码有错误，而牺牲了一些无法衡量和想象的性能优势。

还要考虑机器时间与程序员时间的成本。

【讨论】：

同意，但是 - 我的应用程序处理许多公司 - 每个人都有自己的数据库 - 所以，我更喜欢花很多时间编写处理程序代码，但之后有一个哔哔数据库:)

【解决方案3】：

如果您正确使用索引，您可能不需要将其拆分为多个表。大多数现代数据库都会优化访问。

您可能会考虑的另一种选择是创建一个当前年份的表，最后将数据附加到另一个包含所有前几年数据的表中。 ?

【讨论】：

是的，只有 2 个表（当前年份和历史记录）是我的第一个想法，但我认为年份系统会更快 - 只需要更好的代码编写

【解决方案4】：

我不会按年份拆分表格。

相反，我每年都会将数据归档到报告数据库中，并在需要时使用。

或者，您可以在驱动器之间对数据进行分区，从而保持性能，尽管我不确定这在 postgresql 中是否可行。

【讨论】：

【解决方案5】：

对于您正在查看的数据量，拆分数据似乎很麻烦，收效甚微。 Postgres 可以进行分区，但是精美的手册 [1] 说，根据经验，您可能应该只对超出服务器物理内存的表考虑它。根据我的经验，这至少是一百万行。

http://www.postgresql.org/docs/current/static/ddl-partitioning.html

【讨论】：

在现实生活中，订单表还有另外3个子表，适合于年龄层次。每个订单行，在第一个“孩子”中至少有 3 行，每个子行在孩子的孩子中至少有 4 行，依此类推。我也知道重复这样的结构将是更难——特别是维护

【解决方案6】：

我同意较小的表更快。但是，将单个实体拆分到多个表中是否有意义，这取决于您的业务逻辑。如果您需要大量代码来管理所有表，那么这可能不是一个好主意。

这还取决于数据库您可以使用什么逻辑来解决这个问题。 In Oracle a table can be partitioned（以年份为例）。数据物理存储在不同的表空间中，这应该可以更快地处理（因为我假设一年的所有数据都存储在一起）

索引会加快速度，但如果数据分散在磁盘上，则需要大量读取块，这可能会使其变慢。

【讨论】：

我将在 postgresql 或.. mysql（可能是 postgresql）上运行

【解决方案7】：

考虑按时间片对表进行分区。分区适用于没有外键指向表的类日志表情况。

【讨论】：