2

私のプロジェクトの 1 つで、ログ システムの現在の実装は mysql テーブルを使用しています。顧客にリリースされたアプリケーションは、毎日いくつかのログ情報をテーブルに書き込みます。サーバーには、60 日以上経過したすべてのログを自動的に削除するスクリプトがあります。問題は、プライマリ ID が増え続け、将来的には制限を超えてしまうことです。ID は現在 int auto_increment に設定されています。では、この問題の最善の解決策は何ですか。私はデータベースの専門家ではありません。ご協力をお願いします。Stack Overflow で検索しようとしましたが、私の場合の答えが見つかりませんでした。

int を bigint に変更する必要がありますか? データベースの通常の操作を中断せずにそれを行うにはどうすればよいですか? ダウンタイムは避けたい。しかしbigintでもidはいつか限界に達します。問題を遅らせているだけのようです。良い解決策はありますか？スクリプトが古いデータを削除した後に使用可能になる ID を再利用できるようにデータベースを構成できますか?

4

2 に答える 2

1

テーブルを削除するのではなく、60 日後にコンテンツをアーカイブするようにしてください。つまり、メイン テーブルから削除し、アーカイブされたテーブルに挿入します。2 番目の問題については、PK の値が急激に増加している場合は、タイプ「bigint」を試してください。

于 2012-07-14T17:49:21.113 に答える
0

アプリケーション アクションのログを生成する必要がある時期尚早のデプロイ フェーズにまだアプリケーションがない限り、4294967295 行 (unsigned int の場合) のログ データで十分だと思います。それ以外の場合は、ユーティリティ スクリプトを改善して、テーブルを再構築し、インデックスを再起動できるようにしてください。もちろん、さらに数秒かかりますが、それだけの価値があると思います。いずれにせよ、最良の (理想的な) データベース駆動型アプリケーションは、より小さなデータ (ログを含む) を生成しますが、完全なデータ セットを良好な整合性で提供します。

于 2012-07-14T18:12:55.767 に答える