Mysql 数据库非规范化可提高选定报告的性能

注意：在回答这个问题时，请记住

MySQL

或

MSSQL

RDMBS

背景：

• 假设您有一个名为

  records

  的表。此表有20个字段，其中一些是

  VARCHAR（255）

• 您必须在名为

  amount（FLOAT）

  和

  status（INT）

  的两个字段上运行报告
• 因为一条记录只能有一种状态，所以它保存在同一个表中
• 该表按

  状态

  和

  金额

  编制索引

情况：

索引工作正常，即使有超过1000万条记录，基于这两个字段分组的响应时间也是可以接受的。 然而，随着数据的增长，索引的效率正在降低，因为RDBMS仍然需要解析所有这些数据子集，而不仅仅是解析这两个字段。即使使用适当的索引，这也会导致报告速度越来越慢

问题：

虽然amount与记录有一对一的关系，将amount和status与record id外键一起放在一个单独的表中是没有意义的，但是您认为即使它变得不那么规范化，它是否会更有效

我为什么要问这个问题？

---

因为这听起来很简单，如果我有一个单独的表，其中包含一个记录id和相应的金额，那么当我运行一些关于金额和状态的报告时，它们将比当前的设置快得多，因为数据库现在必须查看更少的数据，更少的数据必须通过数据总线等等计算报表时不需要的所有字段都不会在操作系统级别进行数据分析。我知道，当我运行一个关于数量和状态的报告时，数据库将不关心存储在其中的其他字段和值，但它仍然必须读取所有这些数据子集，以便解析记录，并且在磁盘级别仍然会导致

读取
对数据库进行非规范化，这会给您带来非常好的性能（响应时间）增加，但您必须降低空间使用率

在您的情况下，我认为
分区
数据库水平地可以提高性能

范围–此分区模式允许DBA指定各种
为其分配数据的范围。例如，DBA可以创建
由三个包含
20世纪80年代、90年代及以后的所有数据，包括
2000年
散列–这种分区模式允许DBA基于
在一个或多个表列上定义的计算哈希键，
最终目标是在所有人之间平等分配价值
例如，DBA可以创建一个分区表
有十个基于表主键的分区

Key–一种特殊形式的散列，MySQL保证
通过系统生成的哈希键分发数据

列表–此分区模式允许DBA基于
DBA指定的预定义值列表。例如
DBA可以创建一个包含三个分区的分区表
基于2004年、2005年和2006年

复合–这种最终的分区模式允许DBA执行
子分区，其中表最初由进行分区，例如
示例范围分区，但每个分区都是分段的
甚至可以通过另一种方法（例如，散列法）进一步实现
对数据库进行非规范化可以获得非常好的性能（响应时间），但必须降低空间使用率

在您的情况下，我认为
分区
数据库水平地可以提高性能

范围–此分区模式允许DBA指定各种
为其分配数据的范围。例如，DBA可以创建
由三个包含
20世纪80年代、90年代及以后的所有数据，包括
2000年
散列–这种分区模式允许DBA基于
在一个或多个表列上定义的计算哈希键，
最终目标是在所有人之间平等分配价值
例如，DBA可以创建一个分区表
有十个基于表主键的分区

Key–一种特殊形式的散列，MySQL保证
通过系统生成的哈希键分发数据

列表–此分区模式允许DBA基于
DBA指定的预定义值列表。例如
DBA可以创建一个包含三个分区的分区表
基于2004年、2005年和2006年

复合–这种最终的分区模式允许DBA执行
子分区，其中表最初由进行分区，例如
示例范围分区，但每个分区都是分段的
甚至可以通过另一种方法（例如，散列法）进一步实现
能否提供一个正在运行的报告查询示例和一个创建表输出，以便我们可以看到当前索引的样子？在对数据库进行非规范化之前，您可以尝试以下几点：1）将固定长度字段移到行的前面，将varchar移到行的末尾。2） 只选择状态和数量，而不是整行。@GilbertLeBlanc谢谢，很有意思的是，如果这些可变长度字段移到末尾，这很重要@ØHankyPankyØ：我不知道这有多重要，但数据库引擎可以预先计算超过固定大小列的位移，而数据库引擎必须计算位移p