在過去，我在兩種不同的方式來處理用戶的圖片上傳：推薦架構處理用戶的圖片上傳
第一個選擇得不錯加載它，但我必須保持對上傳的圖片相當的約束大小限制。除了PHP的圖像庫之外，第二種選擇類型的工作方式通常會讓文件轉換更糟糕（然而，我認爲這可以通過使用ImageMagick來解決）。
我現在正面臨第三次這樣做，對於潛在更大規模的用戶。我已經計劃在上傳後使用ImageMagick對圖像進行一些後期處理。我很樂意儘可能縮小圖片上傳的限制，甚至可能保留每個人上傳的照片。
有數百個用戶的照片上傳將會在屏幕上一次顯示爲縮略圖。將它們存儲在一個數據庫中，並將它們拖拽到每個數據庫中並通過PHP進行顯示似乎不是一個好方法，但是將所有圖像放入單個目錄中也不會。
在這種情況下，您有什麼建議？你是否選擇了上述選項之一，還是有不同的解決方案？
將這些數據存儲在數據庫中，併爲每個數據庫拉動它們並通過PHP顯示看起來並不是一個好方法，但將所有圖像放入單個目錄中也不會。
您可以採取混合方法。
將圖像存儲在多個文件夾中（根據您確定適合您的應用程序的任何方案）。存儲數據庫中每個圖像的完整路徑。
在後臺作業中，生成的圖像縮略圖（如ImageMagick）的文件名與圖像本身略有不同（例如：在前面添加'thumb-'），但與真實圖像一起存儲。您可以在每個圖像的數據庫中有一個字段，意思是「我的縮略圖已準備就緒，所以請將我包括在畫廊中」。
當您收到圖庫請求時，使用數據庫字段對圖像組進行切片和裁切，然後生成一段引用相應縮略圖和圖像路徑的HTML。
編輯： 什麼亞倫說˚F當你需要處理一個非常大的請求數量是非常重要的。對image/sql數據進行分區是可擴展性的好路徑。您需要查看應用程序中的訪問模式以確定分區指向的位置。您甚至可以儘快完成的任務是緩存爲畫廊生成的HTML，以減少SQL負載。
您引用的兩個示例沒有闡明最重要的部分：分區。
例如如果存儲在數據庫中，那麼圖像是否完全駐留在一個數據庫服務器上的一個表中？還是表分爲幾個服務器/集羣？
例如如果存儲在一個目錄中，所有圖像都駐留在一個硬盤上？或者根據用戶登錄名中的第一個字母映射到單獨的[RAID]驅動器？是需要的可擴展性
一個好的分區方案。
至於散裝顯示縮略圖，你可能會在這裏需要一些預先計算。即創建縮略圖（可能通過異步作業，在圖像上傳後立即啓動）並將其放置在專用服務器上。這是Youtube如何拍攝上傳視頻的快照。
恕我直言，大衛的解決方案是最適合大多數情況下，但我會修改兩個細節：
商店的完整路徑數據庫中的每個圖像。
我不認爲你需要存儲完整路徑，因爲如果由於某種原因的圖像變化的目錄，將複雜化你的生活一點。僅存儲文件名就夠了。您始終可以直接在html中包含完整路徑。
有生成圖像的縮略圖（用ImageMagick說），它們的文件名與圖像本身略有不同，但與實際圖像一起存儲。
我寧願將縮略圖放在不同的目錄中，爲每個創建的拇指創建一個目錄，並使用完全相同的文件名。我曾經在一個擁有數千個用戶映像的網站上工作，我犯了一個錯誤，把它們放在同一個目錄中。目錄變得非常多，幾乎不可能等待幾分鐘就打開這個目錄。
PHP的圖像庫中經常會誤事文件轉換
我建議增加內存限制在您創建拇指腳本，特別是如果你允許的大（2MB +）的文件上傳。
你可以用ini_set('memory_limit', '30M');做到這一點。當然，實際數量取決於您。 30M在縮略圖很重的網站上爲我工作。
uhm用於創建縮略圖，使用phpthumb ......它絕對是完美的......有一些額外的功能，但你可能不需要那些......它會自動在你的文件系統上創建一個本地緩存，所以它是非常節省資源......
我認爲，混合方法可能是最可擴展的，基於數據庫中的文件系統和文件位置即存儲文件......這樣一來，你可以存儲一些元數據該文件（如創作者，標題，標籤等），並保持你的數據庫的小...加上，您可以將您的圖像存儲在任意位置（甚至在其他機器，等等），讓您可以輕鬆地分發所有的有效載荷...
格爾茨
back2dos
幾年前，我寫的意思，最終存放一些34萬加掃描相對縮略圖內聯網圖像存檔。搜索一下，我發現沒有難以不把它們全部轉儲到一個目錄中，只要你不要求底層操作系統做一個文件夾列表。換句話說，調用ls/dir會掛起機器，但僅僅通過它們的文件名（從數據庫中）檢索單個圖像文件將意味着沒有性能損失。
該檔案已經運行了幾年，現在我可以確認它可以正常工作，並且可以正常存儲在一個文件夾中的60k以上的圖像上。
我從來沒有任何一種將GD轉換成jpeg的問題，但是對於那個特殊的工作，我使用ImageMagick作爲輔助擴展（主要是因爲體面的文檔）而支持MagicWand。
如果你問我，我會使用Thumbnailer類。