注意:回答这个问题时请牢记 MySQL 或 MSSQL RDMBS
背景:
- 假设您有一个名为
records的表。该表有 20 个字段，其中一些是VARCHAR(255)。 - 您必须在名为
amount (FLOAT)和status (INT)的两个字段上运行报告。 - 由于一条记录只能有一个状态，所以它被保存在同一个表中。
- 表在
status和amount上建立索引。
情况:
索引工作正常，即使有超过 1000 万条记录，基于这两个字段的分组响应时间也是可以接受的。 然而，随着数据的增长，索引的效率正在降低，因为 RDBMS 仍然必须解析所有这些数据子集，而不仅仅是解析这两个字段。即使有适当的索引，这也会导致报告越来越慢。
问题:
虽然金额与记录有一对一的关系，将金额和状态与记录 id 外键一起放在单独的表中并没有多大意义，但是，你认为这样做会更有效率吗，即使它变成了规范化程度较低？
我为什么要问这个问题？
因为这对我来说听起来像是简单的逻辑，如果我有一个包含记录 ID 和相应金额的单独表格，那么当我运行一些关于金额和状态的报告时，它们将比当前设置快得多，因为数据库有现在看更少的数据，更少的数据必须通过数据总线等，所有那些计算报告不需要的字段都没有在操作系统级别被解析为数据。我知道当我运行关于数量和状态的报告时，数据库不会关心其他字段和存储在其中的值，但它仍然必须读取所有这些数据子集才能解析记录，并且在磁盘级别仍然结果为 reads。
最佳答案
对数据库进行非规范化可以为您带来非常好的性能(响应时间)增益，但您必须牺牲空间使用率。
在您的情况下，我认为水平分区数据库可以提高性能。
- Range——这种分区模式允许 DBA 指定各种 分配数据的范围。例如，DBA 可以创建一个 由包含的三个分区分割的分区表 1980 年代、1990 年代以及之后的所有数据 2000 年。
Hash – 这种分区模式允许 DBA 根据 在一个或多个表列上定义的计算哈希键， 最终目标是平等分配值(value) 分区。例如，DBA 可能会创建一个分区表 有十个基于表主键的分区。
Key – 一种特殊形式的 Hash，其中 MySQL 保证甚至 通过系统生成的哈希键分发数据。
List – 这种分区模式允许 DBA 根据 DBA 指定的预定义值列表。例如，一个 DBA 可能会创建一个包含三个分区的分区表 基于 2004、2005 和 2006 年。
- 复合——这种最终的分区模式允许 DBA 执行 表最初分区的子分区，对于 示例范围分区，但随后每个分区都被分段 甚至通过另一种方法(例如，散列)。
关于mysql - SELECT 报告性能提升的数据库非规范化，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17481564/