先把負載拆成三條流
把 OLTP 當成一個統一的隨機讀寫負載來評估，幾乎一定會選錯盤。實際上至少存在三條特徵不同的流：預寫日誌是小塊、順序、同步的寫，每次事務提交都要求資料真正進入掉電安全域；資料頁刷新是較大塊、隨機、可批次非同步的寫；索引查詢則是 4 至 8 KB 的隨機讀。把它們混在一起看平均 IOPS，會掩蓋真正的瓶頸。
提交延遲是 QD1 問題
提交路徑上事務是序列等待的：應用發出 fsync 或帶 FUA 的寫後必須等盤返回完成，才能向客戶端應答。此時佇列深度往往只有一到兩個，吞吐指標完全不起作用，起作用的是 QD1 寫延遲。J750/J770 規劃的 QD1 平均 4KB 隨機寫延遲為 10 µs，遠低於讀的 65 µs，原因在於寫在 PLP 保護下於主控緩衝即可安全確認，而讀必須真正穿越 NAND 陣列和糾錯流水線。沒有掉電保護的盤只有兩個選擇：犧牲這條快路徑，或者在掉電時丟失已確認的事務。對資料庫而言後者不可接受。
資料頁刷新決定 DWPD 檔位
盤上實際寫入量通常遠大於應用層的邏輯寫入量。資料庫自身的頁大小（8 或 16 KB）對 4 KB 修改的放大、雙寫緩衝、檢查點重複刷新都會疊加。做容量規劃時應先估算五年累計寫入總量，再回到 DWPD。一塊 3.84 TB 的 1 DWPD 盤每天允許寫入 3.84 TB 並維持五年，同一容量檔的 3 DWPD 產品則是三倍。J750 定為 1 DWPD、J770 定為 3 DWPD，正對應讀多寫少與持續高寫入兩類負載，OLTP 主庫通常落在後者。
為什麼 P99 比平均值更值得看
資料庫的鎖與事務超時對最慢的那一小部分請求最敏感。一次 GC 引起的毫秒級停頓會讓持鎖事務延長，進而在併發場景下放大成連鎖排隊，表現為吞吐驟降而非延遲溫和上升。因此評估用盤必須在充分預處理後的穩態下測 P99 與 P99.9 寫延遲，新盤的平均值沒有參考價值。
指標到選型的換算
J770 規劃 600 KIOPS 4KB 隨機寫、1,500 KIOPS 隨機讀，容量檔 1.6/3.2/6.4/12.8 TB。順序是：按五年寫入總量定 DWPD，按提交延遲預算校驗佇列配置，最後才核對峰值 IOPS 餘量。以上均為產品定義/EVT 階段的規劃值，需在客戶實際負載回放中復核。