最近遇到上面這個問題，一開始我就果斷否決了資料庫儲存圖片的策略，主要是太蠢!事實上我的決定是正確的，我僅僅理解為mysql讀寫效能提高的境界，具體為什麼可以提高？很模糊，知道我看到了這裡:
大佬做的實驗:https://www.oschina.net/translate/repeat-after-me-mysql-is-not-a-filesystem
王滔大佬的總結：http://www.cnblogs.com/wangtao_20/p/3440570.html
我自己無恥地拿來github mysql儲存圖片的策略:https://assets-cdn.github.com/images/icons/emoji/unicode/1f44d.png?v8
當然也可以參考阿里等大廠的儲存方式，很簡單隨便點開一張圖片觀察儲存路徑;
==============================王滔大佬總結如下===========================================================
商品圖片，使用者上傳的頭像，其他方面的圖片。目前業界儲存圖片有兩種做法：
1、 把圖片直接以二進位制形式儲存在資料庫中
一般資料庫提供一個二進位制欄位來儲存二進位制資料。比如mysql中有個blob欄位。oracle資料庫中是blob或bfile型別
2、 圖片儲存在磁碟上，資料庫欄位中儲存的是圖片的路徑。
一、圖片以二進位制形式直接儲存在資料庫中
第一種儲存實現(php語言)：
大體思路：
1、將讀取到的圖片用php程式轉化成二進位制形式。再結合insert into 語句插入資料表中的blob型別欄位中去。
3、 從資料庫取出圖片展示的時候。則是直接傳送圖片內容
4、
$row=mysql_fetch_object($result);
Header( “Content-type: image/gif”);
echo $row->this_image;
實現程式碼如下：
$PicturePath = ‘/tmp/xxxjgjgj.jpg’;//假設這是上傳的圖片，php放在一個臨時資料夾。指令碼執行完畢後自動刪除了。
$imgStream = fread(fopen($PicturePath, “r”);
$blob_img = fread(fopen($imgStream, “r”), filesize($PicturePath));
$sql =” INSERT INTO Images (this_image) VALUES ($blob_img)”;
注：this_image就是資料表中一個blob欄位型別的欄位
================取出展示圖片程式碼
$result=mysql_query(“SELECT * FROM Images WHERE PicNum=$PicNum”) or die(“Cant perform Query”);
$row=mysql_fetch_object($result);
Header( “Content-type: image/gif”);
echo $row-> this_image;
總結：處理程式碼感覺還真比較麻煩。其實，我從來沒用過在資料庫中以二進位制儲存圖片的做法。我們用得更多的是儲存圖片的路徑，實際圖片是在磁碟上儲存的(圖片二進位制放到資料庫,把資料庫的負擔弄重了)。
據我瞭解，網際網路環境中，大訪問量，資料庫速度和效能方面很重要。一般在資料庫儲存圖片的做法比較少，更多的是將圖片路徑儲存在資料庫中，展示圖片的時候只需要連線磁碟路徑把圖片載入進來即可。因為圖片是屬於大欄位。一張圖片可能1m到幾m。
有個原則：圖片儘量不要儲存在資料庫中(是指不要二進位制形式儲存到欄位，而只儲存圖片的路徑)。這樣的大欄位資料會加重資料庫的負擔，拖慢資料庫。在大併發訪問的情況下很重要。這是一個經驗。去看看dba對資料庫效能調優方面的分析都能得到這個答案的：就是圖片不要儲存在資料庫中。
就像這個規則一樣：文章分為標題、作者、新增時間、更新時間、文章內容、文章關鍵字
文章內容一般是比較長的。經常使用text欄位去儲存。文章的內容就屬於大欄位。一般文章內容可以拆分到單獨一個表中去。不要與文章資訊儲存在一張表裡面。
我理解的原理是：mysql中一張表的資料是全部在一個資料檔案中的。如果大欄位的資料也儲存在裡面。程式展示列表，比如文章列表。這個時候根本不需要展示文章內容的。但是仍然會影響速度，資料庫查詢資料其實就是掃描那個資料檔案，檔案容量越小，速度就會越快(為什麼單表的容量在1g-2g的時候基本上要分表了)。拆分出去到一張單獨的表，就是單獨的檔案了。我覺得，舉一反三，相互獨立，分離的思想不僅在系統開發中用到，在現實生活中經常存在的。相互混合，就會造成相互影響。小巧，簡潔是一種思想。
可以看看這篇翻譯的文章，
http://developer.51cto.com/art/201211/364472.htm
作者建議，三種東西永遠不要放到資料庫裡,圖片，檔案，二進位制資料。作者的理由是，
- 對資料庫的讀/寫的速度永遠都趕不上檔案系統處理的速度
- 資料庫備份變的巨大，越來越耗時間
- 對檔案的訪問需要穿越你的應用層和資料庫層
把圖片縮圖存到資料庫裡？很好，那你就不能使用nginx或其它型別的輕量級伺服器來處理它們了。
給自己行個方便吧，在資料庫裡只簡單的存放一個磁碟上你的檔案的相對路徑，或者使用S3（備註：亞馬遜雲服務）或CDN之類的服務。
============================================================
關於mysql中的blob型別
bolb像int型那樣，分為blob、MEDIUMBLOB、LONGBLOB。其實就是從小到大，
blob 容量為64KB ，MEDIUMBLOB 容量為16M，LONGBLOB 容量為4G。
說實話，圖片用這樣子儲存用得還真少。使用php函式serialize進行序列化的值，我看到有人存入這個欄位中去。
php手冊：serialize返回字串，此字串包含了表示 value 的位元組流，可以儲存於任何地方。
mysql中blob欄位儲存圖片有個通訊大小的設定：
圖片要傳輸給mysql儲存起來，那麼需要涉及到資料通訊。mysql中有個配置是限制通訊資料大小的。
my.conf配置檔案中的max_allowed_packet，mysql預設的值是1M。
好多圖片尤其是原始圖可能不止1m。傳輸的資料(也就是圖片)超過這個設定大小。結果就會出錯
呵呵，限制挺多。感覺好麻煩。這樣子明顯佔用與mysql互動的通訊時間嘛。延長響應時長了。我直接丟個圖片路徑”images/xxxx”給mysql。沒這麼耗費資源。
其實所謂的效能，最關鍵是資料庫效能。因為隨著資料庫資料量增大，大部分時間耗費是在php，java等語言等待資料庫返回資料的過程中耗費時間。
網站訪問量大了後，具體的語言不是瓶頸，瓶頸都在資料庫。用c，，php，java,net都能操作mysql資料庫獲取資料。語言之間可能存在速度執行差異，但是其實這種差別已經很小了。至少我覺得，給予使用者感覺不到明顯。執行相差0.0001秒使用者感覺並沒有明顯的區別。可能說，大併發(很多使用者同時訪問)的時候，就會體現到差別了。其實我覺得，大併發訪問是資料庫瓶頸。等待資料庫給予資料。沒達到一定級別實在體現不了差別。資料庫資料量達到一定級別。語言相差0.001s會給予使用者體驗上的差別。我想，這也是為什麼php很適合做web開發了。解析頁面速度快(解釋型語言，不需要編譯)。可以用java來與資料庫打交道獲取資料。php不直接運算元據庫，而是呼叫java提供的資料介面，獲取資料，馬上展示在頁面中。這是利用了php的頁面執行速度快的一個優勢。
備份圖片資料和遷移資料方便
圖片以二進位制形式儲存在資料庫，有一個好處：備份的時候方便。直接備份資料庫，圖片也跟著備份。換句話說，遷移環境的時候是方便。
而圖片放在磁碟上的話，資料庫中儲存的只是圖片路徑。備份資料庫後。磁碟上的圖片也要跟著備份才行。
不過我覺得，備份這個好處不是很明顯。圖片在磁碟上，備份磁碟也沒很大的事情。打包壓縮也可以了。網際網路環境畢竟與傳統的軟體開發不同，web開發比較關注網站速度。也就是資料庫的速度。就像網際網路開發中，有時候為了速度，用空間換時間的做法比較普遍，所以往往在設計資料庫的時候並不一定遵循傳統資料庫設計三大正規化。
資料庫中儲存的是圖片路徑的話，在web開發環境下，其實有個更好處，就是cdn加速。就是下面要進行總結的地方。
二、資料庫中儲存圖片路徑
一般是這樣子的：
按照年月日生成路徑。具體是按照年月日還是按照年月去生成路徑，根據自己需要(不一定是按照日期去生成)。
理解為什麼要分散到多個資料夾中去才是關鍵，涉及到一個原理就明白了：
作業系統對單個目錄的檔案數量是有限制的。當檔案數量很多的時候。從目錄中獲取檔案的速度就會越來越慢。所以為了保持速度，才要按照固定規則去分散到多個目錄中去。
圖片分散到磁碟路徑中去。資料庫欄位中儲存的是類似於這樣子的”images/2012/09/25/ 1343287394783.jpg”
原來上傳的圖片檔名稱會重新命名儲存，比如按照時間戳來生成，1343287394783. jpg。這樣子是為了避免檔名重複，多個人往同一個目錄上傳圖片的時候會出現。
反正用什麼樣的規則命名圖片，只要做到圖片名稱的唯一性即可。
比如網站的併發訪問量大，目錄的生成分得月細越好。比如精確到小時，一個小時都可以是一個資料夾。同時0.001秒有兩個使用者同時在上傳圖片(因為那麼就會往同一個小時資料夾裡面存圖片)。因為時間戳是精確到秒的。為了做到圖片名稱唯一性而不至於覆蓋，生成可以在在時間戳後面繼續加毫秒微秒等。總結的規律是，併發訪問量越大。就越精確就好了。
我現在還沒碰到需要這麼精細的。概率比較少。
有個方面總結一下：為什麼儲存的磁碟路徑，是”images/2012/09/25/1343287394783.jpg”，而不是” /images/2012/09/25/ 1343287394783.jpg”(最前面帶有斜槓)
我的理解：
連那個斜槓都不要。這裡也是做到方便以後系統擴充套件。
在頁面中需要取出圖片路徑展示圖片的時候，如果是相對路徑，則可以使用”./”+”images/2012/09/25/1343287394783.jpg”進行組裝。
如果需要單獨的域名(比如做cdn加速的時候)域名，img1.xxx.com,img2.xxx.com這樣的域名，
直接組裝 “http://img1.xxx.com/”+”images/2012/09/25/1343287394783.jpg”
當然資料庫是可以在前面加斜槓/儲存起來,/images/2012/09/25/ 1343287394783.jpg
其實不方便統一。比如相對路徑載入圖片的時候，則是”.”+” /images/2012/09/25/ 1343287394783.jpg”
可能我還沒體會到壞處，以後會遇到問題的。不過，遵循慣例不加斜槓” images/2012/09/25/ 1343287394783.jpg”就對了。
涉及到一個新問題：為什麼大部分系統都不會域名儲存進去，像這樣子http://www.xxx.com/images/2012/09/25/1343287394783.jpg儲存到資料庫中
曾經與一個上海的網友聊天，他也是習慣不會把域名儲存資料庫中過去。但當時我們兩聊的時候，他對”域名儲存進去的做法”與”不儲存域名進去”也沒有一個明確利弊。他就覺得，沒有什麼明顯的區別啊。
瞭解的知識越多，越有利於我們做決定。可能就是一個”感覺區別不是很大”的影響下，去做一個決定，反而對後面是比較大的影響的。至少是增加自己的工作量了。
其實把域名儲存進去，也不是什麼滔天大罪的事情。但凡是經驗豐富的開發人員都不會這樣子做。這是一個經驗積累出來的，所以上海那個網友也對此並沒有明顯的概念很正常，他說他不知道cdn方面的(當然覺得存個域名進去沒什麼大不了的)。需要了解cdn知識，什麼情況下會用到cdn知識。
雖然是做開發人員，不需要關注運維和伺服器之類的知識。不過了解一些就有利於理解了。
這裡涉及到cdn加速。
關於cdn原理(就是內容分發網路)
cdn，我理解其本質就是為了解決距離遠產生的速度問題，使用就近的服務。
從中國請求美國一臺伺服器上的圖片。一般比較慢，因為距離這麼遠，網路傳輸是存在損耗的，距離越遠，傳輸的時間就越長。一般會看到瀏覽器左下角顯示：“已響應,正在傳輸資料..”。這不是伺服器本身問題了。實際上伺服器早就響應請求，把資料發給客戶端，但是網路問題，就一直在傳輸，沒傳完了。
在中國，是南北距離遠的問題。南北還會涉及到跨網，南方使用者使用電信居多，北方使用者網通居多。兩個線路需要跨越，會有時間延遲。北京到廣州的距離，如果直接請求
cdn加速就是適應這個需求產生的：現在不請求美國的伺服器。直接在中國安放節點(節點是比較籠統的詞語，可以理解成一臺伺服器，也可以理解成一個機房，就是一個點嘛)，請求距離近的節點。這樣子就不需要那麼遠的距離了。
記得以前在長沙的網站，團購以城市分站的形式。北京和長沙用的是同一套程式。伺服器在長沙。北京使用者訪問北京站的時候,實際上需要遠距離訪問長沙的伺服器。速度怎麼都快不起來。跟伺服器效能完全沒關係。當時不懂這些。不清楚怎麼折騰。看那本《前端優化技巧》，想辦法去做js程式碼壓縮，瀏覽器快取之類的。實際上瞎折騰。不是說這些前端優化不重要，哲學上有主次矛盾之分，瓶頸在哪裡就去突破哪裡。沒解決主要矛盾，問題並不會迎刃而解。當時也不是資料庫瓶頸。如果去優化資料庫。也不會明顯改善。就那點資料量。根本就達不到瓶頸。哪裡談得上主要矛盾。隨著後來去其他公司工作，接觸一些東西，類似不找瓶頸的優化例子發生在身邊好幾次了，先沒找到瓶頸就瞎去優化。我的同事可能是抱著多多益善的心態去做的，但主要矛盾(技術上說是瓶頸)沒找到，也沒改善。
當時如果沒想到是距離問題。也就不會想到cdn，當時其實我根本不知道cdn服務。我只知道，google這些網站肯定在中國部署的伺服器，要不然，中國使用者還去訪問美國的伺服器，那再好的伺服器都會速度慢的。
由於自己搭建cdn環境和機房的資金比較大（需要大量的伺服器），也需要人力維護。反正一般的公司弄不起，其實根本不划算。淘寶以前用商用的cdn服務，後來商用的扛不住了，就搭建了自己的cdn網。我不知道新浪有沒有自己搭建，但其實我覺得跟淘寶的特點有關，店鋪很多，無論是商品還是交易記錄總計起來商品很多的圖片，圖片都是靜態的部分，cdn本來就是用來做靜態的(圖片，css，js等)請求分發用的。
我之前在網上看到一句話，cdn網路不是一般的公司玩得起的。
一般的公司自己搭建cdn網路成本高，所以就有商業的cdn提供付費租用服務，這是一項很成熟的業務，很多這樣的公司，大部分全國性的網際網路公司都會使用到cdn。
總結：cdn服務。對於靜態內容是非常適合的。所以像商品圖片，隨著訪問量大了後，租用cdn服務，只需要把圖片上傳到他們的伺服器上去。
例子：北京訪問長沙伺服器，距離太遠。我完全可以把商品圖片，放到北京的雲服務（我覺得現在提供給網站使用的雲端儲存其實就是cdn，給網站提供分流和就近訪問）上去。這樣子北京使用者訪問的時候，實際上圖片就是就近獲取。不需要很長距離的傳輸。
自己用一個域名img.xxx.com來載入圖片。這個域名解析到北京的雲服務上去。
做法:資料庫中儲存的是” images/2012/09/25/1343287394783.jpg”,
這些圖片實際上不儲存在web伺服器上。上傳到北京的cdn伺服器上去。
我從資料庫取出來，直接”img.xxx.com/”+” images/2012/09/25/1343287394783.jpg”
比如如果還有多個，就命名img1.xx.com、img2.xx.com
反正可以隨便。所以如果把域名直接儲存進去。就顯得很麻煩了。遷移麻煩。
像淘寶，凡客，亞馬遜這些電子商務網站，我們看到請求的時候，下面往往會有
img1.xxx.cdn.com
img2.xxx.cdn.com
其實他們儲存在資料庫中的是相對路徑。有些是不需要在資料庫儲存的，縮圖可以實時訪問的時候用程式生成(節省很多儲存空間)
實際上，把域名儲存在資料庫中，非常不利於系統遷移。一旦換個域名的話，原來儲存在資料庫中的是“www.abc.om/images/xxxxxx“,因為路徑都在資料庫中寫死了。下回換個域名就用不了了。那個時候自己去寫sql語句批量更新欄位吧。
幾個術語：
icp，Internet Content Provider，也就是網路內容提供者。聯想到我們運營一個網站需要icp備案了嗎？你自己運營網站，你就是ｉｃｐ服務商
IDC（Internet Data Center)，網際網路資料中心。IDC的概念，目前還沒有一個統一的標準。通俗點，就是提供機房託管(伺服器租用和託管)，域名註冊之類的。
關於淘寶的圖片儲存
瞭解到：淘寶以前使用了商用的儲存。但是沒法滿足需求。據說，到2010年，淘寶網後端儲存著286億張圖片。商用的系統系統沒法滿足需求的時候。他們就自己開發了一個tfs。大規模的小檔案在磁碟上讀取，需要磁碟磁頭頻繁的尋道和換道。大併發情況下和大量的操作確實很麻煩。其實借鑑了當時google公佈的gfs設計論文。google有相簿服務。為每個使用者提供上傳圖片儲存。
估計，google是率先實現這種小檔案網路儲存系統的。
有個觀點比較好：對於老闆們而言，往往覺得，用錢能解決的都不算問題。但問題在於，你遇到的問題，別人都沒遇到過。那這個時候你就沒有經驗可以參考或者直接拿來使用。只有自己參考一些思路去創造技術了。
三、關於圖片進行雲端儲存(cdn加速)
曾經看過這個，這個是比較適合創業公司的。價格相對便宜
介紹提到，我們在全國各地部署了55個CDN節點，500多臺伺服器，電信，聯通，移動和教育網的4線頻寬。
其實，現在的雲端儲存本質就是一個cdn服務商。你把靜態的圖片上傳到他提供的伺服器上去(ftp方式上傳或者api形式編寫程式上傳)。他為你做就近節點訪問。
計費方式：按照流量付費，99元購買100g。怎麼算流量。每次訪問檔案的大小累加，比如一個1m的檔案，訪問一次流量就加1m。
我個人理解，對於圖片的量不大的情況下，使用這種雲服務，好處不是節省儲存空間。你自己的伺服器100g的空間可能創業型公司都沒用完，不是什麼儲存空間不夠用，然後去用雲端儲存。以前我對cdn比較模糊，有這麼點理解，或者以為是分散網站web伺服器流壓力，伺服器分流。這些好處是有的。但是，只要理解了cdn產生的背景和解決的關鍵問題後，就會明白雲端儲存關鍵好處在於：給使用者就近節點訪問，加速。
我覺得，如果不是出於這個考慮，或者達不到這樣的目的。用其他方案也完全可以替代。何必使用雲端儲存呢？就是你無非有實力做到全國多個節點去部署服務，才需要租用cdn來幫你，畢竟他們是規模產生的效益，專注於解決這個領域。
還有：騰訊雲、阿里雲