動態網站壹般都是用數據庫來存儲信息，如果信息的及時性要求不高 可以加入緩存來減少頻繁讀寫數據庫。
兩種方式壹般都支持，但是繞過操作系統直接操作磁盤的性能較高，而且安全性也較高，數據庫系中的磁盤性能壹直都是瓶頸，大型數據庫壹般基於unix
系統，當然win下也有，不常用應為win的不可靠性，unix下，用的是裸設備raw設備，就是沒有加工過的設備（unix下的磁盤分區屬於特殊設備，
以文件形式統壹管理），由dbms直接管理，不通過操作系統，效率很高，可靠性也高，因為磁盤，cache和內存都是自己管理的，大型數據庫系統
db2，oracal，informix（不太流行了），mssql算不上大型數據庫系統。
1、直接讀文件相比數據庫查詢效率更勝壹籌，而且文中還沒算上連接和斷開的時間。
2、壹次讀取的內容越大，直接讀文件的優勢會越明
顯（讀文件時間都是小幅增長，這跟文件存儲的連續性和簇大小等有關系），這個結果恰恰跟書生預料的相反，說明MYSQL對更大文件讀取可能又附加了某些操
作（兩次時間增長了近30%），如果只是單純的賦值轉換應該是差異偏小才對。
3、寫文件和INSERT幾乎不用測試就可以推測出，數據庫效率只會更差。
4、很小的配置文件如果不需要使用到數據庫特性，更加適合放到獨立文件裏存取，無需單獨創建數據表或記錄，很大的文件比如圖片、音樂等采用文件存儲更為方便，只把路徑或縮略圖等索引信息放到數據庫裏更合理壹些。
5、PHP上如果只是讀文件，file_get_contents比fopen、fclose更有效率，不包括判斷存在這個函數時間會少3秒左右。
6、fetch_row和fetch_object應該是從fetch_array轉換而來的，書生沒看過PHP的源碼，單從執行上就可以說明fetch_array效率更高，這跟網上的說法似乎相反。
磁盤讀寫與數據庫的關系：
壹 磁盤物理結構
(1) 盤片：硬盤的盤體由多個盤片疊在壹起構成。
在硬盤出廠時，由硬盤生產商完成了低級格式化(物理格式化)，作用是將空白的盤片(Platter)劃分為壹個個同圓心、不同半徑的磁道
(Track)，還將磁道劃分為若幹個扇區(Sector)，每個扇區可存儲128×2的N次方（N=0.1.2.3）字節信息，默認每個扇區的大小為
512字節。通常使用者無需再進行低級格式化操作。
(2) 磁頭：每張盤片的正反兩面各有壹個磁頭。
(3) 主軸：所有磁片都由主軸電機帶動旋轉。
(4) 控制集成電路板：復雜！上面還有ROM（內有軟件系統）、Cache等。
二 磁盤如何完成單次IO操作
(1) 尋道
當控制器對磁盤發出壹個IO操作命令的時候，磁盤的驅動臂(Actuator
Arm)帶動磁頭(Head)離開著陸區(Landing
Zone，位於內圈沒有數據的區域)，移動到要操作的初始數據塊所在的磁道(Track)的正上方，這個過程被稱為尋道(Seeking)，對應消耗的時
間被稱為尋道時間(Seek Time)；
(2) 旋轉延遲
找到對應磁道還不能馬上讀取數據，這時候磁頭要等到磁盤盤片(Platter)旋轉到初始數據塊所在的扇區(Sector)落在讀寫磁頭正下方之後才能開始讀取數據，在這個等待盤片旋轉到可操作扇區的過程中消耗的時間稱為旋轉延時(Rotational Delay)；
(3) 數據傳送
接下來就隨著盤片的旋轉，磁頭不斷的讀/寫相應的數據塊，直到完成這次IO所需要操作的全部數據，這個過程稱為數據傳送(Data Transfer)，對應的時間稱為傳送時間(Transfer Time)。完成這三個步驟之後單次IO操作也就完成了。
根據磁盤單次IO操作的過程，可以發現：
單次IO時間 = 尋道時間 + 旋轉延遲 + 傳送時間
進而推算IOPS(IO per second)的公式為：
IOPS = 1000ms/單次IO時間
三 磁盤IOPS計算
不同磁盤，它的尋道時間，旋轉延遲，數據傳送所需的時間各是多少？
1. 尋道時間
考慮到被讀寫的數據可能在磁盤的任意壹個磁道，既有可能在磁盤的最內圈（尋道時間最短），也可能在磁盤的最外圈（尋道時間最長），所以在計算中我們只考慮平均尋道時間。
在購買磁盤時，該參數都有標明，目前的SATA/SAS磁盤，按轉速不同，尋道時間不同，不過通常都在10ms以下：
3. 傳送時間2. 旋轉延時
和尋道壹樣，當磁頭定位到磁道之後有可能正好在要讀寫扇區之上，這時候是不需要額外的延時就可以立刻讀寫到數據，但是最壞的情況確實要磁盤旋轉整整
壹圈之後磁頭才能讀取到數據，所以這裏也考慮的是平均旋轉延時，對於15000rpm的磁盤就是(60s/15000)*(1/2) = 2ms。
(1) 磁盤傳輸速率
磁盤傳輸速率分兩種：內部傳輸速率(Internal Transfer Rate)，外部傳輸速率(External Transfer Rate)。
內部傳輸速率(Internal Transfer Rate)，是指磁頭與硬盤緩存之間的數據傳輸速率，簡單的說就是硬盤磁頭將數據從盤片上讀取出來，然後存儲在緩存內的速度。
理想的內部傳輸速率不存在尋道，旋轉延時，就壹直在同壹個磁道上讀數據並傳到緩存，顯然這是不可能的，因為單個磁道的存儲空間是有限的；
實際的內部傳輸速率包含了尋道和旋轉延時，目前家用磁盤，穩定的內部傳輸速率壹般在30MB/s到45MB/s之間(服務器磁盤，應該會更高)。
外部傳輸速率(External Transfer Rate)，是指硬盤緩存和系統總線之間的數據傳輸速率，也就是計算機通過硬盤接口從緩存中將數據讀出交給相應的硬盤控制器的速率。
硬盤廠商在硬盤參數中，通常也會給出壹個最大傳輸速率，比如現在SATA3.0的6Gbit/s，換算壹下就是6*1024/8，768MB/s，通常指的是硬盤接口對外的最大傳輸速率，當然實際使用中是達不到這個值的。
這裏計算IOPS，保守選擇實際內部傳輸速率，以40M/s為例。
(2) 單次IO操作的大小
有了傳送速率，還要知道單次IO操作的大小(IO Chunk Size)，才可以算出單次IO的傳送時間。那麽磁盤單次IO的大小是多少？答案是：不確定。
操作系統為了提高 IO的性能而引入了文件系統緩存(File System Cache)，系統會根據請求數據的情況將多個來自IO的請求先放在緩存裏面，然後再壹次性的提交給磁盤，也就是說對於數據庫發出的多個8K數據塊的讀操作有可能放在壹個磁盤讀IO裏就處理了。
還有，有些存儲系統也是提供了緩存（Cache），接收到操作系統的IO請求之後也是會將多個操作系統的 IO請求合並成壹個來處理。
不管是操作系統層面的緩存還是磁盤控制器層面的緩存，目的都只有壹個，提高數據讀寫的效率。因此每次單獨的IO操作大小都是不壹樣的，它主要取決於系統對於數據讀寫效率的判斷。這裏以SQL Server數據庫的數據頁大小為例：8K。
(3) 傳送時間
傳送時間 = IO Chunk Size/Internal Transfer Rate = 8k/40M/s = 0.2ms
可以發現：
(3.1) 如果IO Chunk Size大的話，傳送時間會變大，從而導致IOPS變小；
(3.2) 機械磁盤的主要讀寫成本，都花在了尋址時間上，即：尋道時間 + 旋轉延遲，也就是磁盤臂的擺動，和磁盤的旋轉延遲。
(3.3) 如果粗略的計算IOPS，可以忽略傳送時間，1000ms/(尋道時間 + 旋轉延遲)即可。
4. IOPS計算示例
以15000rpm為例：
(1) 單次IO時間
單次IO時間 = 尋道時間 + 旋轉延遲 + 傳送時間 = 3ms + 2ms + 0.2 ms = 5.2 ms
(2) IOPS
IOPS = 1000ms/單次IO時間 = 1000ms/5.2ms = 192 (次)
這裏計算的是單塊磁盤的隨機訪問IOPS。
考慮壹種極端的情況，如果磁盤全部為順序訪問，那麽就可以忽略：尋道時間 + 旋轉延遲 的時長，IOPS的計算公式就變為：IOPS = 1000ms/傳送時間
IOPS = 1000ms/傳送時間= 1000ms/0.2ms = 5000 (次)
顯然這種極端的情況太過理想，畢竟每個磁道的空間是有限的，尋道時間 + 旋轉延遲 時長確實可以減少，不過是無法完全避免的。
四 數據庫中的磁盤讀寫
1. 隨機訪問和連續訪問
(1) 隨機訪問(Random Access)
指的是本次IO所給出的扇區地址和上次IO給出扇區地址相差比較大，這樣的話磁頭在兩次IO操作之間需要作比較大的移動動作才能重新開始讀/寫數據。
(2) 連續訪問(Sequential Access)
相反的，如果當次IO給出的扇區地址與上次IO結束的扇區地址壹致或者是接近的話，那磁頭就能很快的開始這次IO操作，這樣的多個IO操作稱為連續訪問。
(3) 以SQL Server數據庫為例
數據文件，SQL Server統壹區上的對象，是以extent(8*8k)為單位進行空間分配的，數據存放是很隨機的，哪個數據頁有空間，就寫在哪裏，除非通過文件組給每個表預分配足夠大的、單獨使用的文件，否則不能保證數據的連續性，通常為隨機訪問。
另外哪怕聚集索引表，也只是邏輯上的連續，並不是物理上。
日誌文件，由於有VLF的存在，日誌的讀寫理論上為連續訪問，但如果日誌文件設置為自動增長，且增量不大，VLF就會很多很小，那麽就也並不是嚴格的連續訪問了。
2. 順序IO和並發IO
(1) 順序IO模式(Queue Mode)
磁盤控制器可能會壹次對磁盤組發出壹連串的IO命令，如果磁盤組壹次只能執行壹個IO命令，稱為順序IO；
(2) 並發IO模式(Burst Mode)
當磁盤組能同時執行多個IO命令時，稱為並發IO。並發IO只能發生在由多個磁盤組成的磁盤組上，單塊磁盤只能壹次處理壹個IO命令。
(3) 以SQL Server數據庫為例
有的時候，盡管磁盤的IOPS(Disk Transfers/sec)還沒有太大，但是發現數據庫出現IO等待，為什麽？通常是因為有了磁盤請求隊列，有過多的IO請求堆積。
磁盤的請求隊列和繁忙程度，通過以下性能計數器查看：
LogicalDisk/Avg.Disk Queue Length
LogicalDisk/Current Disk Queue Length
LogicalDisk/%Disk Time
這種情況下，可以做的是：
(1) 簡化業務邏輯，減少IO請求數；
(2) 同壹個實例下，多個數據庫遷移的不同實例下；
(3) 同壹個數據庫的日誌，數據文件分離到不同的存儲單元；
(4) 借助HA策略，做讀寫操作的分離。
3. IOPS和吞吐量(throughput)
(1) IOPS
IOPS即每秒進行讀寫（I/O）操作的次數。在計算傳送時間時，有提到，如果IO Chunk Size大的話，那麽IOPS會變小，假設以100M為單位讀寫數據，那麽IOPS就會很小。
(2) 吞吐量(throughput)
吞吐量指每秒可以讀寫的字節數。同樣假設以100M為單位讀寫數據，盡管IOPS很小，但是每秒讀寫了N*100M的數據，吞吐量並不小。
(3) 以SQL Server數據庫為例
對於OLTP的系統，經常讀寫小塊數據，多為隨機訪問，用IOPS來衡量讀寫性能；
對於數據倉庫，日誌文件，經常讀寫大塊數據，多為順序訪問，用吞吐量來衡量讀寫性能。
磁盤當前的IOPS，通過以下性能計數器查看：
LogicalDisk/Disk Transfers/sec
LogicalDisk/Disk Reads/sec
LogicalDisk/Disk Writes/sec
磁盤當前的吞吐量，通過以下性能計數器查看：
LogicalDisk/Disk Bytes/sec
LogicalDisk/Disk Read Bytes/sec
LogicalDisk/Disk Write Bytes/sec