メールを mysql データベースに保存していますが、圧縮 ( https://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html#function_compress ) を使用して保存することをお勧めします。データベース内の取得された電子メールの添付ファイルを削除して、データベースのサイズを縮小します。
私が躊躇しているのは、ほとんどの添付ファイルが既に圧縮されているためです (jpg など)。もう 1 つの理由は、MySql のビルトイン圧縮アルゴリズムの有効性について何も見つけられなかったことです。
あなたが提供した追加情報を考えると、（a）ファイルを検索できる必要はなく、ファイルを取得するだけで、（b）DBは1GBに制限されているようです。ファイルをDBに保存するのではなく、ファイルに「キー」を保存することをお勧めします。これはおそらく一意のファイル名です。
データベースでは、元のユーザー ファイル名を保存できますが、一意の識別子を使用してファイルストアに添付ファイルを書き込むことができます (列 ID だけにすることも、適切な GUID を作成することもできます)。
これにより、データベースが小さく保たれ、添付ファイルをファイルから取得するのに、DB から取得するよりも時間がかかりません。取得時にファイルを書き戻す場合は、名前を変更した一意のファイル名ではなく、元のファイル名を渡します。
大量のファイルが予想される場合は、ディレクトリ間でストレージを分割して、ファイルが大きくなりすぎないようにし、最終的に必要に応じて複数のファイル システムにまたがることができます。
DB とストレージの両方の制限が 1GB である場合、もちろん、これはおそらくあまり役に立ちません。その場合、はい、ファイルを圧縮する必要がありますが、既に認識しているように、既に圧縮された形式のファイルではあまり良い圧縮率が得られない場合があります。
データベースの外部にファイルを保持することを支持する最後の 1 つのポイントは、DB を無駄のない状態に保つのに役立つ可能性があるため、バックアップ/復元または移行アクティビティが高速になることです。
私にとっては、そのメールの実際の使用に大きく依存します。
最初に、どのくらいのトラフィックを期待しており、どのくらいのストレージを持っていますか? (多くのスペースがあり、ユーザーが少ない場合は、なぜ気にする必要がありますか?)
2 つ目: 現在の形式 (jpg、odf ドキュメント、オフィス ドキュメント、mp3) の多くは既に圧縮されているため、あまり活用できません。
3 番目: 圧縮すると CPU 使用率が増加する可能性があるため、ピーク時にトラフィックがどのようなものになるかを確認して、これが問題になるかどうかを確認する必要があります (ほとんどの場合はそうではありません)。
最後に、サーバーでサーバーグレードのファイルシステムを使用する予定がある場合は、一部のデータが透過的に圧縮されるため、他の方法に時間を投資することをお勧めします
一方、リソースが非常に限られている場合は、スペースの消費を減らすために al を圧縮する必要があるかもしれません