これで、bigint が 2^64 であることがわかりました。つまり、既知の宇宙に存在するよりも多くの原子です。私の単なる人間の脳は、その数の巨大さを単に回避することができないので、私は心配するべきではありません.
しかし、私はすべてのカテゴリ、製品、および注文に対するすべての変更を、発売から終了までシステムに記録しているとしましょう。主キー値の不足を心配する前に、テーブル書き込みのパフォーマンスを心配する必要がありますか? 異なる優先度のイベントを異なるイベント テーブルに記録する必要がありますか? bigint を使い果たす前に、ハード ドライブの Atom を使い果たすことはありますか? アーカイブ/クリアを開始する前に、イベント ログ テーブルをどれくらい大きくする必要がありますか?
すべてのエントリが 1 バイトしかない場合でも、2^64 エントリはハード ドライブで約 18000000 TB を占有するため、これについて心配する必要はないと思います。
アプリケーションが 100 万分の 1 秒ごとにテーブルにレコードを追加した場合、キーがなくなるまで 50 万年以上実行されます。
「アーカイブ/クリアを開始する前に、イベント ログ テーブルをどれくらい大きくする必要がありますか?」
イベント ログは決して消去しないでください。情報には重要な価値があります。
ただし、一部の管理者がアーカイブが必要であると主張する場合は、ストレージのコストと時間のコストを比較して、(a) 検討し、(b) セカンドオピニオンとサードオピニオンを取得し、(c) アーカイブを作成することをお勧めします。ログ記録をアーカイブする手順。
ストレージのコストは急落しています。ログ レコードを削除する以外のことに時間を費やしたほうがよいでしょう。
結論：手を絞るのをやめる許可があります。大丈夫だよー。あなたは根本的な間違いを犯していません。
これを処理する方法は、ログ アーカイブ機能を提供することです。これは、ログ テーブルを年ごとに別々のデータベースに分離し、LogEvent テーブルの ID シードをリセットできるようにします。
主要なものは 2 つだけですが、さまざまなログ テーブルもあります。
主キーの値が不足することはほとんどありません。ただし、ログ テーブルにアクセスしてデータを取得する方法を考慮する必要がある場合があります。これを使用して、いつデータをアーカイブまたはクリーニングする必要があるかを通知します。ログ データが頻繁に読み取られる場合は、読み取りパフォーマンスを向上させるためにインデックスを追加することを検討してください。ただし、レコードを追加するたびにインデックスを維持する必要があることに注意してください。