我們在像這樣的 Windows 資料夾結構中有數十萬張 jpg 圖像，但以快速的方式互動和使用它們確實很難（列出需要時間，複製需要時間等）。結構如下：
images/
1/
10001/
10001-a.jpg
10001-b.jpg
...
10001-j.jpg (10 images in each XXXXX folder)
10002/
10003/
...
19999/
2/
20001/
20002/
20003/
...
29999/
3/
4/
5/
6/
7/
8/
9/
現在，瀏覽這些圖像有點慢，因為有大約。每個 X 資料夾中有 10,000 個資料夾，列出這些資料夾很需要時間。
有沒有更好的方法來組織具有較少子資料夾/項目的圖像？改變結構會有什麼影響嗎？
images/
1/
0/
0/
0/
0/
1/
2/
3/
4/
5/
6/
7/
8/
9/
10000/ (image folder, same as path)
10000-a.jpg
10000-b.jpg
...
10000-j.jpg (10 images in each image folder)
1/
2/
3/
4/
5/
6/
7/
8/
9/
1/
2/
3/
4/
5/
6/
7/
8/
9/
1/
2/
3/
4/
5/
6/
7/
8/
9/
2/
3/
4/
5/
6/
7/
8/
9/
因此，定位影像 48617-c.jpg 將等於路徑 4/8/6/1/7/48617/48617-c.jpg。
擁有完整路徑號 48617 的單獨資料夾的原因是為了簡化完整 10 個影像批次的複製（透過複製整個資料夾）。
現在... 任何資料夾都不會包含超過 11 個直接子資料夾，但會有許多額外的個位數資料夾用於分隔目的。此設定是否會加快多個使用者新增/複製/刪除/等影像的瀏覽和互動速度？
答案1
當談到包含大量文件的資料夾佈局時，Windows 有點特殊。尤其是映像，因為 Windows 資源管理器會對它們進行特殊對待。也就是說，有一些指導方針需要遵循，以防止事情變得更糟。也不可收拾：
- 如果您出於任何原因打算從 Windows 資源管理器瀏覽目錄結構，請將目錄中的項目數控制在 10,000 個以下（檔案和子目錄）。
- 如果您僅透過 cli 實用程式或程式碼與其進行交互，則 10K 限制要靈活得多。
- 不要建立太多的子目錄，您建立的每個目錄都是複製時必須進行的另一個離散操作。
- 如果每個檔案建立N個目錄，則目錄數檔案系統對象該文件創建的大小將為 1+N，這會線性縮放您的複製時間。
- 一個短的指數樹（即三層目錄，每層有 256 個子目錄）在達到 10K/每個目錄的限制之前可以驚人地擴展。
- 如果您使用程式碼存取它，請直接打開，而不是在打開之前解析目錄列表。在許多情況下，失敗的 fopen() 後跟目錄掃描比目錄掃描後跟有保證的 fopen() 更快。
注意事項：
- 檔案計數是不可變的，但目錄計數取決於您。這兩個計數的總和會影響複製操作的速度。
- 如果可能的話，除非必要，否則盡量不要使用 Windows 資源管理器進行瀏覽。它不能很好地處理大目錄，並且您對此無能為力。
答案2
我的回答中有很多關於數學的好信息目錄複雜度如何影響 i 節點？
話雖如此，不同的檔案系統以不同的方式處理目錄中的大量檔案。有些人可以接受 10,000 個條目，有些人則屈服了。作為一個快速發明的經驗法則，如果您有設計控制能力，1,000 可能是一個不錯的目標上限。目錄中的條目通常儲存為某種列表，由閱讀應用程式對其順序進行排序。例如，ls在 Unix 世界中，按目錄順序將內容讀入內存，然後按字母順序列印出來。
看一下另一個問題的數學。另請考慮 sysadmin1338 關於資源管理器行為不同的說法。 Explorer 將建立它識別為圖像的任何內容的縮圖，然後讀取縮圖以顯示它們。查看充滿檔案的目錄需要大量磁碟 IO。
答案3
根據您是否有資源來開發這樣的系統，這聽起來像是使用 SQL Server 資料庫的良好候選者文件流文件的儲存。這樣，您就可以將目錄的組織工作交給 SQL Server，而您只需擔心如何管理資料本身。您可能可以使用 SQL Express，因為計算資料庫大小時不考慮 FILESTREAM 資料。