あなたの最善のアプローチは、最初からデータベースに保存することではないと思います。ファイルの保存と提供に関して言えば、それはファイルシステムが最も得意とすることです。データベースが通常のファイル システムよりも効率的にこれを実行できる理由は考えられません。
それらをデータベースに格納する場合、サイズ制限がある場合は、BLOB フィールド (TEXT など) を使用し、効率のために URL をハッシュして、巨大な VARCHAR フィールドにインデックスを付けるのではなく、列に格納します。
ただし、静的であると述べたように、実際にはこれには何の意味もありません。静的であるため、Webサーバーに長いキャッシュヘッダーをページに追加させて、同じクライアントからの将来のヒットのためにローカルに保存されるようにします。
[編集1 - コメントに応じて]
私は提供された情報で質問に答え、OPによって情報が提供されなかった場合は一般的なものにしました。
インデックスを作成する VARCHAR の量によって異なります。これは、インデックスを作成する保存されたデータの長さ (URL / パス / ページ名) に関連しています。
わずか 10 万行に対して約 45 文字未満のインデックスを作成している場合、実際には大きな違いはないと思います。ハッシュはメモリの使用量を減らしますが、小さなセットのサイズとパフォーマンスはおそらくそれほど大きな違いはありません。
OPがデータベースについて尋ねたので、私はそれに答えましたが、そもそもそれらをそこに置きたい理由はまだわかりません.ファイルシステムを使用するよりも遅くなります.0データベースに接続する理由、対処するネットワーク パフォーマンス (同じボックス上にある場合を除き、Web ホストでは可能性は低い) インデックスをクエリし、行をフェッチし、データベース プロバイダーを介してそのデータを実行し、Web サーバーが同じ結果を多くの場合に実行できる場合、出力を応答ストリームにストリーミングします。 CPU サイクルが少なくなり、データベースと比較してメモリ使用量がわずかになりますか?
はい - ファイルシステムはデータベースです。過去 10 年間に私が遭遇したすべてのファイルシステムは、ディレクトリ内のこの数のファイルを簡単に収容できます。ディレクトリはツリーとして実装されます (B ツリーを使用するものもありますが、H ツリーなどのより大きなファンアウトを持つ構造この種のアプリケーションではうまく機能します)。
（実際には、ディレクトリの階層に構造化することをお勧めします-たとえば、ファイル名の最初の2文字またはコンテンツのmd5ハッシュにdirsを使用します-パフォーマンスを損なうことなく、コンテンツの管理がはるかに簡単になります） .
リレーショナル データベースは、構造化されたデータの小さな断片を保存するためのものであり、可変サイズの大きなデータを効率的に管理する方法ではありません。
手元にベンチマークはありませんが、数ペタバイトのデータをスポーツ バイクですばやく移動するためにステーション ワゴンを選ぶのと同じように、適切なファイル システム (BTRFS や Ext4 など - ZFS が行う) を使用します。仕事もそうですが、Solaris 以外では良い選択ではありません。また、solaris が Web サーバーに適しているかどうかも疑問です)。
問題は、安価なホスティング会社がこのレベルの情報を前もって提供することはめったにないことです。
ファイルシステムの動作を微調整すると、パフォーマンスが大幅に低下する可能性があることに注意してください。あなたの場合、Linuxで実行している場合は、vfs_cache_pressureを大幅に減らすことをお勧めします。ただし、これには root アクセスが必要です。
別の方法として、リレーショナル データベース (キー/値ストアではなく) ではなく、ドキュメント データベースを使用する方法があります。これらは、大規模なデータ構造の高速レプリケーションと処理を提供するように設計されたスキーマ フリー (NoSQL) データベースの一種です。したがって、これにより、よりスケーラブルなソリューションが提供されます (懸念がある場合)。例: RavenDB。キー/値ストアを使用できますが、これらは大規模なデータ ペイロードを処理するように最適化されることはほとんどありません。
ここで説明した以外の非常に強い理由がある場合にのみ、MySQL を検討します。