bigint 对于事件日志表是否足够大？答案

【问题标题】：Is bigint large enough for an event log table?bigint 对于事件日志表是否足够大？
【发布时间】：2008-11-10 10:58:36
【问题描述】：

现在我知道 bigint 是 2^64；也就是说，原子比已知宇宙中的原子还要多。我不应该担心，因为我的人类大脑根本无法绕过这个巨大的数字。

但是，假设我记录了系统中每个类别、产品和订单的每次更改，从发布到结束。在担心主键值用完之前，我是否应该关注表写入的性能？我应该将不同优先级的事件记录到不同的事件表中吗？在我用完 bigint 之前，我会用完硬盘上的原子吗？在开始归档/清除之前，我应该让事件日志表达到多大？

【问题讨论】：

顺便说一下，已知宇宙中原子的估计值在 10^50 到 10^70 之间变化，因此 2^64（大约 10^20）要小得多——即使是人类也有更多（大约 10^27) 个原子；)

【解决方案1】：

即使你的每个条目只有 1 个字节，2^64 个条目也会在你的硬盘上占用大约 18000000 TB，所以我想你不应该担心这个。

【讨论】：

【解决方案2】：

如果您的应用程序每百万分之一秒向表中添加一条记录，那么它会运行超过 50 万年，然后才会用完键。

【讨论】：

【解决方案3】：

“在我开始归档/清除它之前，我应该让事件日志表变得多大？”

永远不要清除事件日志——这些信息具有重要价值。

但是，当一些经理坚持认为存档是必要的时，您可以显示存储成本与您的时间成本，以 (a) 考虑它，(b) 获得第二和第三意见，然后 (c ) 编写一个过程来归档日志记录。

存储成本直线下降。除了清除日志记录之外，您最好将时间花在其他任何事情上。

底线：您有权停止绞手。都很好。你没有犯一个根本性的错误。

【讨论】：

【解决方案4】：

您极不可能用完主键值。但是，您可能需要考虑如何访问日志表以检索数据。使用它来通知您何时应该归档或清理数据。如果频繁读取日志数据，请考虑添加索引以提高读取性能，但请记住，需要为添加的每条记录维护索引。

【讨论】：

【解决方案5】：

我们处理此问题的方式是提供日志归档功能，按年份将日志表分离到单独的数据库中，从而允许我们重置 LogEvent 表上的身份种子。

我们也有不同的日志表，虽然只有两个主要的。

【讨论】：