如果您有数据库架构，大小估算非常简单...只需为每个表估计行数*平均行大小*为索引使用某些因子*为开销使用某些其他因子。鉴于如今存储的价格荒谬地低，如果您打算拥有非常高的流量站点（或正在为大型企业构建应用程序），大小通常不是问题。

对于我的尺码练习，我总是创建一个Excel电子表格清单：

• col 1: each table that will grow
• col 2: estimated column size in bytes
• col 3: estimated # of rows (per year or max, depending on application)
• col 4: index factor (I always set this to 2)
• col 5: overhead factor (I always set this to 1.2)
• col 6: total column (col 2 X 3 X 4 X 5)

第6列（总计列）的总和，加上没有增长表的数据库的初始大小，就是您的大小估计。您可以更加科学，但这是我快速和粗略的方法。

确定：

• how many visitors per day, V
• how many records of each type will be created per visit, N1, N2, N3...
• the size of each record type, S1, S2, S3...

编辑：忘记了指数因素，一个好的经验法则是2倍。

每天总增长=2*V*(N1*S1+N2*S2+N3*S3+...)

我的基本原则是

• how many users do I expect?
• what content can they post?
• how big is a user record?
• how big is each content item a user can add?
• how much will I be adding?
• how long will those content items live? forever? just a couple weeks?

将用户记录大小乘以用户数量；将用户数量乘以内容项目大小；乘以二（为方便起见使用一个骗过因子）。

估计成本很可能比储存成本更高。

大多数托管提供商通过每月使用的数量出售容量，因此只需让其运行。