我有一个数据库，其中大多数表都有表的删除标志。因此系统会软删除项目（因此除非管理员等，否则它们将不再可访问）
让我担心的是几年后，当表格更大时，系统的整体速度将会降低。
我能做些什么来抵消这样的影响。
我会很感激任何和所有的建议或故事。
更新：
所以分区似乎是关键。但是分区不会只创建两个“表”，一个包含已删除项目，一个不包含已删除项目。
因此，随着时间的推移，删除的分区会变大，偶尔从中获取数据会很慢（随着时间的推移会变慢）
速度差异是我应该担心的吗？因为我通过某个键值获取大部分（如果不是全部）数据（有些是搜索，但对于此设置它们可能很慢）
我会在DELETE旗帜上对桌子进行分区。
删除的行将物理保存在其他位置，但从SQL的角度来看，表保持不变。
哦，地狱是的，索引删除字段。你会一直质疑它，对吧？与您经常查询的其他字段（例如父 ID）的复合索引也可能是一个好主意。
可以说，当且仅当实际出现性能问题时，才可以稍后做出此决定。这在很大程度上取决于以什么速率添加多少行，您的盒子规格等。显然，您的应用程序中的抽象级别（以及您使用的任何库的限制）将有助于确定这种更改的难度.
如果它成为问题，或者您确定它会成为问题，请首先在两个表之间对已删除标志进行分区，一个保存当前数据，另一个保存历史/已删除数据。如果如您所说，“已删除”的数据仅对管理员可用，则可以合理地假设（在大多数应用程序中）用户总数（此处仅限于管理员）不足以引起问题。这意味着您的管理员在搜索该特定表时可能需要等待一段时间，但您的用户群（可以说在大多数应用程序中更重要）将经历更少的延迟。如果管理员无法接受性能，
根据访问数据的方式，您可以使用其他简单的技巧。如果管理员大部分时间都在寻找特定的记录（而不是阅读用户活动的“历史”或“日志”），人们通常可以假设最近的记录会比旧的记录更频繁地被查看记录。一些数据库包含调整选项，使最近的记录比旧记录更容易找到，但您必须为您的特定数据库查找它。如果做不到这一点，您可以手动执行此操作。最简单的方法是拥有一个包含所有早于n的记录的 Ancient_history 表几天、几周或几个月，具体取决于您的限制和可疑的使用模式。然后，较新的数据存在于一个小得多的表中。即使管理员要“浏览”所有记录而不是搜索特定记录，您也可以从显示前n天开始，并有一个链接可以查看所有天，如果他们找不到他们正在寻找的内容（例如，大多数允许您浏览交易但仅显示前 30 天历史记录的在线银行应用程序，除非您另有要求。）
希望您可以避免更进一步，并在 user_id 或某些此类方案上进行分片。根据应用程序其余部分的规模，您可能无论如何都必须这样做。除非您确定需要这样做，否则我强烈建议您首先使用垂直分区（例如，将您的 forum_posts 保存在与 sales_records 不同的机器上），因为它更容易设置和维护。如果您最终需要对 user_id 进行分片，我建议您使用 google ;-]
祝你好运。顺便说一句，我不是 DBA，所以对此持保留态度。