压缩mysql分区

我有一个表，它被时间戳划分为每天一个单独的分区

每天大约收到10亿件事件。每个事件都标记有一个对象，业务逻辑需要一个对象的所有事件来决定如何处理它们。因此，系统有一个大表，每个对象有一行（每天只有数亿行），这些事件被连接到一个“事件缓冲区”媒介文本中

每个对象一行非常有效。它非常快速，适合我们的业务逻辑和报告使用。很久以前，我们从一个事件表开始，然后加入，但速度太慢了

5天后，不会再收到对象的事件。此时，如果没有终止事件，系统会将自己的“超时”事件添加到缓冲区

当接收到对象的事件时，我们正在执行很多业务逻辑，并且我们有一个bool来标记哪些对象没有最终事件等等

虽然“在线”系统只需要5天的对象事件，但报告系统需要一年的时间

我想超过5天的分区被压缩。我可以运行cron作业来触发它

当前的方法是：使用另一个表，该表与联机表具有相同的模式和分区，但row_format=compressed。然后每天创建一个新表，就像这些表一样，但不进行分区。首先，我们

更改表交换分区

以交换5天的分区。然后我们将其插入到新表中

当前方法存在两个问题：1）报告工具必须扫描两个单独的表，2）当对象不在两个主表中时存在竞争条件

---

是否可以

更改单个现有分区的
行格式
？
否，您不能压缩单个分区。表的基本属性在所有分区中都是统一的

请提供
SHOW CREATE TABLE
、表大小，并进一步讨论要压缩的“原因”。可能有一种解决方法可以实现类似的功能

报告

“报告”通常需要“摘要”信息，而不是所有原始数据。所以每天（或每小时，或任何时候）汇总数据，并将汇总放在一个小得多的表格中。然后扔掉原始数据

如果您担心以后需要原始数据，请将日志压缩保存在常规文件中。当然，调出旧数据还需要一些额外的工作。但也有一些取舍

这也解决了干扰——不同的表，更小的表

为了总结，我通常会定期这样做，但也可以在将数据插入原始（“事实”）表时这样做。见和。在后面的链接中，它解释了一种在“staging table”中收集数据的方法，对其进行汇总，将其发送到事实表、规范化表（可能您没有）并进行增量汇总

您的原始数据可能分为6个小时的块：
按范围（到_天（…））分区
。30个分区是一个相当不错的数字（折衷方案）。可能需要对汇总表进行分区。如果你在一年后清洗，请考虑12或52。（实际上是14或54；请参见链接了解原因。）

迁移分区

假设您可以将6天的分区移动到另一个更压缩的表中；并使用
联合前面的
视图
来掩盖拆分的存在

如果您有5.7，那么“导出表空间”就相当容易；这将把分区变成一个表。然后，您可以将其导入到另一个分区表中（除非以某种方式进行压缩，否则这似乎不是很有用），或者转换数据以缩小它

手动压缩

对于大型文本列，我建议在客户端压缩，存储到
BLOB
（而不是
text
）中，并在退出时解压缩。这节省了磁盘空间（对于典型的英语、代码、xml等来说是3倍）和带宽（到/从客户机——如果客户机和服务器距离较远，尤其方便）

数据库API层

有用户发出SQL查询吗？您应该认真考虑在客户机和数据库之间提供一个简单的层。使用它，您可以隐藏视图、联合、压缩、两个表等，并且您可以在不让客户进行更改的情况下进行更改。一定要创建一个理解客户机并且感觉更“通用”的API
GetObject（1234）
执行任何需要的SQL操作，然后以约定的格式（JSON、XML、PHP结构等）返回“object#1234”。
Thx。添加了一些背景。叹气。我的报表需要每行对象数据。数据每天占用几GB的空间，压缩后的数据足够小，可以放在一个大盒子里一年。但是压缩在线系统正在构建的分区对其性能影响太大。因此，我希望在这两个世界中都能做到最好，压缩我不打算再次写入的分区，因为它们已经超过5天了。只要我有多个表，我的用户就必须知道如何查询多个表。我想建立一个视图联盟，但临时表让这很难。我添加了更多想法。是的，这似乎是不可能的。如果能够有一个表来容纳所有对象，每行一个，那将是一件非常好的事情，即使对象已经不到5天了，并且可能仍然在接收事件。这对于各种报告工具来说都很容易使用。但似乎您不能有选择地压缩分区，所以这是不可能的。“接收事件”？？一个对象有两部分吗？静态的、不变的列，以及反映事件的其他列？行（对象）的哪一部分用于每一行？我想知道一个垂直的