Mysql 如何通过软删除项目解决此缩放问题？

我有一个数据库，其中大多数表都有一个表的删除标志。因此，系统软件会删除项目（因此，除非管理员（例如）可以访问，否则这些项目将不再可访问）

让我担心的是，几年后，当表格变得更大时，系统的整体速度将会降低

我能做些什么来抵消这种影响呢

• 是否为删除字段编制索引
• 我是否将删除的数据移动到相同的删除表中，并在取消删除时返回
• 随着时间的推移，我是否将数据分散在几个MySQL服务器上？（基于增长）

我很感激任何和所有的建议或故事

更新：

所以分区似乎是解决这个问题的关键。但是分区不只是创建两个“表”，一个包含删除的项，另一个不包含删除的项吗

因此，随着时间的推移，被删除的分区将变得越来越大，偶尔从中获取数据的速度会变慢（并且随着时间的推移会变慢）

---

我应该担心速度差吗？由于我通过某个键值获取大多数（如果不是全部的话）数据（有些是搜索，但在这个设置中可能会比较慢）

因此我会在

删除

标志上对表进行分区

---

删除的行将被物理地保存在其他位置，但从

SQL

的角度来看，表保持不变。

哦，是的，为delete字段编制索引。你会一直质疑它，对吗？将索引与您经常查询的其他字段（如父ID）组合也可能是一个好主意。

可以说，只有在性能问题确实出现的情况下，才可以在以后做出此决定。这在很大程度上取决于以何种速率添加多少行、您的方框规格等。显然，应用程序中的抽象级别（以及您正在使用的任何库的限制）将有助于确定此类更改的难度

如果出现问题，或者您确信会出现问题，那么首先在两个表之间使用deleted标志进行分区，一个表保存当前数据，另一个表保存历史/已删除数据。如您所说，如果“已删除”数据仅对管理员可用，那么可以合理地假设（在大多数应用程序中）用户总数（此处仅限于管理员）不足以引起问题。这意味着您的管理员在搜索特定表时可能需要等待更长的时间，但您的用户群（在大多数应用程序中可能更重要）将经历更少的延迟。如果管理员无法接受性能，您可能希望索引您访问已删除记录的用户id（或事务id或任何内容）字段（我通常为访问表的每个字段编制索引，但在一定范围内，对于哪些索引最有价值，可能存在权衡）

根据数据的访问方式，您还可以使用其他简单的技巧。如果管理员大部分时间都在寻找特定的记录（与读取用户活动的“历史记录”或“日志”相反），通常可以假设查看最近的记录的频率将高于查看旧记录的频率。有些数据库包括一些调优选项，使最近的记录比旧记录更容易找到，但您必须查找特定的数据库。否则，您可以手动执行此操作。最简单的方法是根据您的限制和可疑的使用模式，创建一个包含所有超过n天、数周或数月的记录的古老_历史表。然后，较新的数据存储在更小的表中。即使管理员打算“浏览”所有记录，而不是搜索特定记录，您也可以从显示前n天开始，并提供一个链接，以便在他们找不到要查找的内容时查看所有天（例如，大多数在线银行应用程序允许您浏览交易，但仅显示前30天的历史记录，除非您另有要求。）

希望您可以避免再进一步，在用户id或类似方案上进行切分。根据应用程序其余部分的规模，您可能必须这样做。除非您肯定需要这样做，否则我强烈建议首先使用垂直分区（例如，将论坛帖子放在一台单独的机器上，而不是放在销售记录上），因为设置和维护起来要容易得多。如果你最终需要分享用户id，我建议使用谷歌；-]

---

祝你好运。顺便说一句，我不是DBA，所以对此持保留态度。

是的，实际上很少有查询不检查删除字段中的某个值。对；我实际上不是说“一直”，更像是“非常普遍”。如果您的大多数查询都与delete字段相反，那么似乎需要对其进行索引。@嗯，这将带来一个问题。