SQL與測試資料
儲存一百萬列需要多少 GB？
使用工具
預估百萬筆還不足以選磁碟：短 ID 與長文字列不同，另有索引與管理資訊。DB 容量概算把假設寫明；小數精細只表示算術，不是實測精度。
先假設每列 200 byte
rows = 1000000
averageRowBytes = 200
indexFactor = 0.3
overheadFactor = 0.15
replicas = 1
base = 200000000 byte
index = 60000000 byte
overhead = 30000000 byte
total = 290000000 byte = 0.29 GB輸入百萬列、200 位元組、索引係數 0.3、管理係數 0.15、副本 1。30% 應填 0.3 而非 30。範例係數非通用常數，有結構或實測依據時應替換。
兩個係數都乘 200 MB 基礎，不把管理係數乘含索引的 260 MB。公式為 200×(1+0.3+0.15)。依次設零可分辨各項增量。
字元數總和不是資料列大小
一百字元不一定一百位元組，DB 還有列頁資訊及不同變長儲存。匯出 JSON 大小除列數得到的是 JSON 表示均值，不一定是 DB 資料列大小，應記錄樣本測量對象。
只有短值或空列會低估長文，全按最大值又可能高估。可試 200、400、800 位元組等合理範圍；只輸入彙總假設，不需原始紀錄。
副本 2 是總共兩份
兩份為 580000000 位元組，數量包含主副本。baseBytes、indexBytes、overheadBytes 是單份，bytes 含全部。別把差額誤認為壓縮或誤差。
副本數不模擬歷史備份世代。備份、日誌、暫存空間另算後彙總；若平均列大小已含管理資訊，別再用係數重複加。
GB 與 GiB 讓容量看似減少
290000000 位元組是 0.29 GB、約 0.2701 GiB，並未消失。比較帳單、系統與結果須統一單位，分享時保留位元組數與假設。
說明是什麼推動容量成長
列數或均值翻倍會使模型總量翻倍，但新增一個索引不等於再加 30%，結構不同。逐項改變假設，以敏感程度決定下一步測什麼。
不能單憑結果決定購買容量、警報或效能保證。更新、維護空間與引擎儲存行為在公式外。取得實測後替換假設，比增加小數位更有用。