Mysql 会话/日志表密钥设计问题

我几乎总是听到有人说不要在用户会话和任何日志表中使用FKs，因为这些通常是高写表，一旦写入数据，几乎总是永远不会更新或删除

但问题是我有这样的colunms： 用户id（将会话或活动日志链接到用户） 活动\标识（将日志活动表链接到系统活动查找表） 会话\u id（将用户日志表与父会话链接） ... 还有4-5个colunms

因此，如果我不使用FKs，那么我将如何“关联”这些colunms？我可以在没有FKs的情况下联接表并获取用户信息吗？我可以在没有FKs的情况下写入正确的数据吗？对性能有任何影响，或者人们只是说这是一个禁忌

---

---

另一个问题是，如果我不使用FKs，我还可以将数据与查找表连接吗？

事实上，您可以在mysql中构建整个数据库，而不需要真正的FKs。如果您将MyISAM用作存储引擎，那么FKs无论如何都不是真的。 不过，只要连接键匹配，就可以执行所有喜欢的连接

性能影响取决于在引用表中填充了多少数据。如果表中有FK并向其中插入数据或更新FK值，则需要额外的时间。插入或修改时，需要在引用表中查找FK，以确保引用完整性

在不需要引用完整性的高度使用的表上，我只使用松散的列而不是FKs

---

AFAIK InnoDB是目前唯一一个支持真正外键的数据库（除非MySQL 5.5有新的或更新的存储引擎也支持外键）。像MyISAM这样的存储引擎确实支持语法，但实际上并不验证引用完整性。

FK在“历史记录”表中可能有害。这种表希望保留在某个时间点发生的事情的确切状态

---

FK的问题是它们不存储值，只存储指向值的指针。如果值更改，则历史记录将丢失。您不希望更新级联到历史记录日志中。有一个可以加入的“伪外键”是可以的，但您也希望有意地对相关字段进行反规范化以保留历史记录。

我为所有表提供了InnoDB。该网站是一个社交网络，因此数据非常重要。社交网络中的日志表（其中，我们跟踪用户的每个移动-因此您可以想象，每个用户、每个登录名至少添加150-200行跟踪详细信息。因此，表大小将增加。对于它所引用的父表，用户表将随着新用户的加入而增加。活动表大部分是只读的，除非添加新活动，否则很少更新。）ded。我不应该说“指针”。我假设代理项值上有一个外键。如果您加入代理项键以获取最新值，则会破坏日志的用途。日志与最新值无关。它与当时的值有关。