ディレクトリ内のファイルの数が多すぎますか（WindowsおよびLinuxの場合）？
重複の可能性：
ディレクトリ内のファイルの数が多すぎますか？
ディレクトリに入れるファイルが多すぎると、LinuxやWindowsでパフォーマンスの問題が発生する可能性があると言われました。これは本当ですか？もしそうなら、これを回避するための最良の方法は何ですか？
このMicrosoftの記事 によると、ディレクトリのルックアップ時間は、エントリ数の2乗に比例して増加します。 （それはNT 3.5に対するバグでしたが。）
同様の質問が ソフトウェアフォーラムのOld Joel で尋ねられました。 1つの答えは、パフォーマンスが1000〜3000ファイルの間で低下しているようであり、1つのポスターが18000ファイルで厳しい制限に達したというものでした。さらに別の投稿では、300,000ファイルが可能であると主張していますが、8.3ファイル名がすべて使い果たされると、検索時間は急速に減少します。
大きなディレクトリを回避するには、1つ、2つ、またはそれ以上のレベルのサブディレクトリを作成し、ファイルをそれらにハッシュします。最も単純な種類のハッシュは、ファイル名の文字を使用します。したがって、3レベルのネストを選択したとすると、abc0001.txtで始まるファイルはa\b\c\abc0001.txtとして配置されます。 3はおそらくやり過ぎです-ディレクトリごとに2文字を使用すると、ネストレベルの数が減ります。例えばab\abc0001.txt。ディレクトリの数が約2を大幅に超えると予想される場合は、2つのレベルのネストに進む必要があります。 3000ファイル。
Windowsファイルシステムは現在NTFSです。ボリューム上のファイルの最大量は4,294,967,295です。ドライブ上のファイルのカタログ化は、Log（N）ルックアップを提供するB +ツリーで行われます。
古いFAT32では、フォルダ内のファイル数は64Kに制限されていました。インデックス作成もフォルダごとのリストによって行われたため、数千のパフォーマンスが大幅に低下しました。聴衆がDOS、Windows 95、98、またはMillenium（Yuck）を持っていない限り、おそらくFAT32について心配する必要はありません。
Linuxでは、実際には使用しているファイルシステムによって異なります（そうすることにした場合はNTFSになる可能性があります）。extf3にはディレクトリあたり32kファイルの制限があります。ルックアップもB +ツリーであり、LOG（N）ルックアップを提供します
これをさらに詳しく調べた後、あなたの質問は本当にファイルシステムの制限に関するものでなければなりません。