MySQL：分区是处理删除的好方法吗？

我有一个MySQL表：

CREATE TABLE responses (
    id INT NOT NULL AUTO_INCREMENT,
    other_id INT NOT NULL,
    details TEXT,
    deleted BOOLEAN,
    PRIMARY KEY (id)
);

用户可以删除

响应

中的记录

我的计划是使用

deleted

字段执行删除。每当用户删除记录时，我都会将

deleted

设置为

1

有时我可能会想清除所有已删除的记录或将其存档。我正在考虑使用分区来加快速度：

PARTITION BY LIST(deleted) (
    PARTITION pActive VALUES IN (0),
    PARTITION pDeleted VALUES IN (1)
);

我的问题是，这会使删除的动作变慢吗？现在，当我更改记录的“已删除”字段时，MySQL需要将记录移动到完全不同的分区。这看起来可能很慢

---

如果您有任何建议，我们将不胜感激。

是的，我希望这两个状态之间的转换会更慢，以便在分区之间传递。但是，对现有值的已删除/未删除查询会更快，尽管不涉及删除状态的查询不会得到改进

---

这都是关于什么是表中最常见的操作，并接受可能存在的妥协。

我过去在一个项目中使用过这种方法，我个人感觉这不是最好的方法。我认为最好是删除记录。当您有这样的标志时，使用数据库的每个人都必须了解表中存在的记录可能不是“真实”记录，这取决于是否设置了“已删除”标志。在我看来，它只是让数据库变得不那么直观，更难使用

如果您关心性能，我会考虑正确分配表空间，您仍然可以使用分区方案。您可以按年份和月份对数据进行分区（如果需要这种粒度级别），以提高性能

---

但我会避免删除标志。在我参与的项目中，这真是一件令人头疼的事。例如，如果有人试图插入另一条与“已删除”记录完全相同的记录（此处删除意味着删除标志为true），该怎么办。您是将现有记录的“删除”设置为false，还是插入另一条全新记录？如果插入一条全新的记录，那么既然有两条记录具有相同的键，那么如何在表上定义主键？您是否将

删除
作为钥匙的一部分？关键是，您必须处理所有这些类型的非琐碎问题。
我曾经在使用“软删除”方法的系统上工作过，例如。他们想知道总共创建了多少，以及系统中实际使用了什么。基于替换/后续内容删除了一些内容，但他们希望能够在必要时进行恢复。这取决于业务规则，但它可能会影响资源/驱动器空间…@OMG Ponies-我只记得我参与的项目是一场噩梦。我认为如果要保存已删除的数据，更好的方法是使用触发器将记录复制到另一个表中，但我会避免像瘟疫一样的deleted标志：）。您的里程数可能会有所不同。@dcp：移动东西的触发器需要一个重复的表——当时我所知道的DBA中没有一个允许在他们的数据模型中使用这种东西。@OMG Ponies——我们称之为审计表。所以我会有一个人和一个人的审计。person_audit表将跟踪person表的插入/更新/删除。这是我喜欢使用的方法，因为它提供了完整的审计跟踪。我还没有看到DBA对它的反对。也许“审计”这个词是让他们对额外的表感觉更好所需要的：）。无论如何，如果DBA反对拥有审计表，我真的必须质疑它们。我相信这是一种可行的方法，特别是如果需要某种方法来取消删除。但有时“审计表”方法可能更好。。。视情况而定。