我正在开发一个跟踪和处理工单/票据的应用程序。每张票证都通过外键链接到创建/拥有该票证的用户，该外键级联 MySQL 中的任何更改。显然，如果用户由于某种原因删除了他们的帐户，我们仍然希望保留他们的门票和基本信息的记录。
首先想到的实现此目的的方法是在用户表中有一列，表示他们是活动的还是非活动的，即删除或未删除。这样，当他们关闭/删除他们的帐户时，他们只需翻转这个值，然后就无法访问该应用程序。
我的另一个想法是在删除帐户时将用户记录移动到已删除的用户表中。这种方式将使用户表的性能保持在最佳状态，当它变大时这可能是一个大问题，但会添加额外的查询来移动记录。
显然其中一部分可能是偏好，但我对性能方面感兴趣。本质上，问题是选择查询与插入查询相比如何，以及在什么情况下通过添加插入查询（将记录移动到已删除的用户表）来提高整体性能？
用户表中有一个列表示他们是活动的还是非活动的，即删除或未删除。
好。
我的另一个想法是将用户记录移动到已删除的用户表中
不好。您现在有两个联接：用户到票证和前用户到票证。这是不必要的复杂性。
当它变大时可能会是一件大事，
如果“大”指的是数百万用户，那么你是对的。 但是，如果“大”指的是数千个用户，那么您将无法测量太大的差异。
还有。如果将来确实有明显的减速，您可以使用“物化视图”之类的东西来自动创建“活跃”用户的子集视图/表。
显然其中一部分可能是偏好，
其实不然。停用（但不是删除）用户有很多优点，但没有真正的缺点。
有很多级别的活动——安全锁定（但未禁用）——暂时禁用——委托给其他用户。很多很多的状态变化。删除的原因很少。没有理由“移到另一张桌子”。
选择查询与插入查询相比如何？通过添加插入查询（将记录移动到已删除的用户表），整体性能在什么时候会提高？
只有您可以衡量您的表、索引、服务器和事务组合的这一点。没有通用答案。
在我看来，将用户标记为已删除或未删除是更好的方法。第二种方法，使用新表，将导致引用用户表的每个表发生更改。您应该有“已删除用户表”的新外键。这将更改此表中选择行的所有查询。
正如您所写，该应用程序是关于票证的，从逻辑上讲，大多数查询都是关于选择和编辑票证的。所以影响会在这个表上，我不认为你对用户有很大的疑问。
对“用户”表进行优化并对“票证”表进行更复杂的查询不会有回报。
我在开发的应用程序中遇到了类似的问题。该问题涉及系统其他元素的日志和用户信息。
我通过在日志表中添加一列来解决这个问题，其中包含一个存储为字符串的 JSON 对象，其中包含日志记录所需的信息。如果您想从表中物理删除用户，并且还需要有关已删除用户的信息，那么这种方法很好。