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%，结构不同。逐项改变假设，以敏感程度决定下一步测什么。
不能单凭结果决定购买容量、报警或性能保证。更新、维护空间和引擎存储行为在公式外。获得实测后替换假设，比增加小数位更有用。