一 磁盤實體結構
(1) 盤片：硬碟的盤體由多個盤片疊在一起構成。
在硬碟出廠時，由硬碟生産商完成了低級格式化(實體格式化)，作用是将空白的盤片(platter)劃分為一個個同圓心、不同半徑的磁道(track)，還将磁道劃分為若幹個扇區(sector)，每個扇區可存儲128×2的n次方（n=0.1.2.3）位元組資訊，預設每個扇區的大小為512位元組。通常使用者無需再進行低級格式化操作。
(2) 磁頭：每張盤片的正反兩面各有一個磁頭。
(3) 主軸：所有盤片都由主軸電機帶動旋轉。
(4) 控制內建電路闆：複雜！上面還有rom（内有軟體系統）、cache等。
二 磁盤如何完成單次io操作
(1) 尋道
(2) 旋轉延遲
找到對應磁道還不能馬上讀取資料，這時候磁頭要等到磁盤盤片(platter)旋轉到初始資料塊所在的扇區(sector)落在讀寫磁頭正下方之後才能開始讀取資料，在這個等待盤片旋轉到可操作扇區的過程中消耗的時間稱為旋轉延時(rotational latency)；
(3) 資料傳送
接下來就随着盤片的旋轉，磁頭不斷的讀/寫相應的資料塊，直到完成這次io所需要操作的全部資料，這個過程稱為資料傳送(data transfer)，對應的時間稱為傳送時間(transfer time)。完成這三個步驟之後單次io操作也就完成了。
根據磁盤單次io操作的過程，可以發現：
單次io時間 = 尋道時間 + 旋轉延遲 + 傳送時間
進而推算iops(io per second)的公式為：
iops = 1000ms/單次io時間
三 磁盤iops計算
不同磁盤，它的尋道時間，旋轉延遲，資料傳送所需的時間各是多少？
1. 尋道時間
考慮到被讀寫的資料可能在磁盤的任意一個磁道，既有可能在磁盤的最内圈（尋道時間最短），也可能在磁盤的最外圈（尋道時間最長），是以在計算中我們隻考慮平均尋道時間。
在購買磁盤時，該參數都有标明，目前的sata/sas磁盤，按轉速不同，尋道時間不同，不過通常都在10ms以下：
2. 旋轉延時
和尋道一樣，當磁頭定位到磁道之後有可能正好在要讀寫扇區之上，這時候是不需要額外的延時就可以立刻讀寫到資料，但是最壞的情況确實要磁盤旋轉整整一圈之後磁頭才能讀取到資料，是以這裡也考慮的是平均旋轉延時，對于15000rpm的磁盤就是(60s/15000)*(1/2) = 2ms。
3. 傳送時間
(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大的話，傳送時間會變長，單次io時間就也變長，進而導緻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指令。
有的時候，盡管磁盤的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的資料，吞吐量并不小。
對于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
最新内容請見作者的github頁：http://qaseven.github.io/