MySQL数据库中历史数据的最佳实践答案

【问题标题】：Best practices with historical data in MySQL databaseMySQL数据库中历史数据的最佳实践
【发布时间】：2013-06-11 19:48:57
【问题描述】：

最近我想到了将历史数据存储在 MySQL 数据库中的最佳实践。目前，每个可版本化的表都有两列 - valid_from 和 valid_to，都是 DATETIME 类型。具有当前数据的记录有 valid_from 填充其创建日期。当我更新这一行时，我用更新日期填充valid_to，并用valid_from 添加新记录，与上一行中的valid_to 相同——简单的东西。但我知道该表会非常快，因此获取数据可能会非常慢。
我想知道您是否有存储历史数据的做法？

【问题讨论】：

做一些归档，即将历史数据移动到另一个表，并保持当前表是最新的。
@PradeepPati 如果他需要能够同时选择历史和当前数据的查询，这将使应用程序变得非常复杂。但是，他可以创建一些视图来“合并”历史表和当前表。
@Kamil 这真的不会使任何事情复杂化，而是保持应用程序健全。你需要历史，你去历史表，你需要当前数据，去当前表。

标签： mysql sql

【解决方案1】：

担心“大型”表和性能是一个常见的错误。如果您可以使用索引来访问您的数据，那么您是否拥有 1000 条记录中的 1000000 条并不重要 - 至少不是您可以测量的那样。你提到的设计是常用的；这是一个很棒的设计，时间是业务逻辑的关键部分。

例如，如果您想知道客户下订单时某件商品的价格，那么能够搜索其中 valid_from order_date 的产品记录是迄今为止最最简单的解决方案。

情况并非总是如此 - 如果您只是为了存档目的而保留数据，那么创建存档表可能更有意义。但是，您必须确保时间真的不是业务逻辑的一部分，否则搜索多个表的痛苦将是巨大的 - 想象一下每次都必须搜索 product 表或 product_archive 表您想了解下订单时产品的价格。

【讨论】：

【解决方案2】：

这不是完整的答案，只是一些建议。

您可以添加索引布尔字段，例如is_valid。这应该可以提高包含历史和当前记录的大表的性能。

通常 - 将历史数据存储在单独的表中可能会使您的应用程序复杂化（想象一下查询的复杂性，它应该获取具有混合当前和历史记录的数据......）。

今天的计算机速度非常快。我认为您应该将性能与历史记录的单个表和单独的表进行比较/测试。

此外 - 尝试测试您的硬件，看看 MySQL 与大表的速度有多快，以确定如何设计数据库。如果它对您来说太慢 - 您可以调整 MySQL 配置（从增加缓存/RAM 开始）。

【讨论】：

【解决方案3】：

我即将完成一个完全可以做到这一点的应用程序。我的大多数索引首先按关键字段索引，然后将valid_to 字段设置为当前记录的NULL，从而可以轻松快速地找到当前记录。由于我的大多数应用程序都处理实时操作，因此索引提供了快速的性能。偶尔有人需要查看历史记录，在这种情况下，性能会受到影响，但从测试来看，它并不算太糟糕，因为大多数记录在其生命周期内没有太多变化。

如果您的各种键的过期记录比当前记录多得多，则可能需要在任何键字段之前对 valid_to 进行索引。

【讨论】：