在另一个表中复制数据以获得性能提升答案

【问题标题】：Duplicating Data in Another Table for Performance Gain在另一个表中复制数据以获得性能提升
【发布时间】：2018-10-29 22:00:12
【问题描述】：

我目前正在为我正在构建的产品设计数据库架构。在开始在 MySQL 中创建所有内容之前，我只是在 Excel 文件中绘制所有内容。

目前，我有两张几乎完全相同的不同表格。

TABLE A 包含每个用户的每个数据点的最新值。

TABLE B 包含每个用户的每个数据点的每日记录。

我创建TABLE A 的原因是，TABLE B 中的行数每天都会随着我拥有的客户数量而增长。例如，假设我有 20,000 个客户，TABLE B 每天将增长 20,000 行。因此，通过创建TABLE A，我只需搜索 20,000 条记录即可找到每个用户的每个数据点的最新值，因为我每天都会更新这些值；而对于TABLE B，我必须搜索越来越多的行，以查找每个用户的最新插入。

这是可以接受的还是好的做法？

或者我应该忘记 TABLE A 以减少数据库中的“膨胀”吗？

【问题讨论】：

您是在谈论制作一组针对您的阅读要求进行优化的衍生数据。这很正常。这里的关键是以一种可以验证表 A 准确反映 B 中的内容并且两者不会不同步的方式来执行此操作。一种方法是使表 A 成为 VIEW 并定期实现它，或使用触发器进行更新。
@tadman 我对 MySQL 很陌生，所以我无法理解这个 VIEW 东西，并将其具体化，并触发。每次我将每日记录插入TABLE B 时，我都会更新TABLE A。
您可以使用触发器自动执行更新，VIEW 部分是您最初填充表格的方式。如果您不完全熟悉这些概念，则值得一读，这样您就知道自己拥有哪些工具。
@tadman 我今天会详细阅读它们！问题是这一切无论如何都将是自动化的。从抓取到上传，再到数据的处理/处理（即插入和更新）。但我仍然会阅读其他内容
@tadman 刚刚发现不幸的是我的托管计划不允许我在共享主机上使用分区:( 希望我在花这么多时间阅读它之前检查过它哈哈

标签： mysql sql database select database-design

【解决方案1】：

这不是正确的方法。你基本上有两个合理的选择：

使用历史表上的索引来访问最近一天的记录。
使用表分区将每一天存储在一个单独的分区中。

您可以管理两个表，但这很麻烦，并且有内置方法可以处理这种情况。

【讨论】：

难道我每次在TABLE B 中插入新的每日记录时都必须更新索引吗？我对 MySQL 很陌生，所以我真的不了解分区。这是否意味着，即使所有每日记录都将存储在TABLE B 中，TABLE B 也可以/将根据日期列的值划分为“单独的”表？？
@Anthony 。 . .索引会自动更新。我的猜测是，对于每天 30,000 条记录，您不会注意到时间的增加。这将比不使用索引插入需要更长的时间，但不会更长。
哦，我不担心插入数据。我关心的是选择数据。你确定索引会自动更新吗？新记录将每天不断地插入到table b，最新的记录是那些需要访问/必须访问select 的记录。我是关于分区如何大致工作的假设还是我误解了它？
@Anthony 。 . .分区和索引是不同的东西。但是，如果您在 where 子句中有 where date = ?，则两者都很有效。
是的，我知道它们是不同的东西。好的，我明白你现在在说什么。无论如何，我刚刚发现不幸的是我的托管计划不允许我在共享主机上使用分区:(希望我在花这么多时间阅读它之前检查过它。最近一天的记录索引应该足够了使执行时间合理吗？

【解决方案2】：

在我需要“当前”数据和“历史”的情况下，这就是我所做的——一张包含当前数据的表格，一张包含历史记录。对于不同的用途等，它们可能被不同的索引。

我会思考“历史”和“当前”之间的不同之处，然后让表格不同不完全相同。

当有新记录出现时（或在你的情况下为 20K 行），我至少会将其放入 Current。我也可以将它写到History，从而保持它的完整性（以少量冗余为代价）。或者，当下一行进入Current 时，我可以将行移至History。

我认为不需要PARTITIONing，除非我打算清除“旧”数据。在这种情况下，我会使用PARTITION BY RANGE(TO_DAYS(..)) 并选择每周/每月/任何方式，这样分区数不会超过大约 50。（如果您选择“每天”，History 几个月后会变慢，因为的分区。）

每天有 20K 行 -- 其中许多行自昨天以来没有变化吗？这可能不是做事的正确方法。请详细说明每天发生的事情。您应该避免在History 中出现重复的行（日期除外）。

【讨论】：

20k 行通常几乎都是唯一的，如果不是完全唯一的话。我正在做的是抓取与 instagram 主题标签有关的数据点。表 A 和表 B 中的相应记录也将彼此唯一。其中一张表将包含最少量的数据（总共 4 列）；这是我每天将提供大约 2 万条每日记录的表格。而另一个表将保存一堆衍生指标，这些指标随着时间的推移从这些记录的聚合中得出。 [续]
ive 决定在“衍生指标”表（15 列）中保留 2 天的指标（而不仅仅是最新的指标），并在以下情况下清除每个唯一主题标签的两条记录中最旧的一条记录我每天都抓取并插入一条新记录。所以分区最适合这个？具有 15 列的“衍生指标”表将始终具有大约 40k 行。不再。不少于。 [2 * 唯一标签的总数]
@Anthony - 听起来像 Summary Table
基本上就是这样。我的蜘蛛会抓取数据，创建一个 excel 文件，将其上传到服务器以便对其进行解析，然后服务器上的 php 脚本将处理文件/数据并每天为每个主题标签插入一条记录。将有 4 列：(1) unique_key，(2) hashtag，(3) data，(4) date_inserted。当 php 脚本解析 excel 文件以创建每日记录时，我还会选择所有必要的以前的每日记录来运行我的计算，从中将在另一个表中创建值的“摘要”。从未听说过“摘要”
table 直到现在，但这基本上就是这个想法。我认为每天将我的指标值存储/缓存在一个不同的、小得多的表中比不断地检索特定主题标签的所有每日记录然后每次对这些记录运行计算要高效得多用户提交请求或其他任何内容的时间