数据库到底得准备多少存储空间才够用，真没个准儿啊

“数据库到底得准备多少存储空间才够用，真没个准儿啊”，这个话算是说到很多人的心坎里去了，这不像买硬盘，电影快装不下了，买个2T的，心里门清，数据库这东西，就跟家里有个特别能吃的半大小子，你永远猜不到他下个月饭量能长多少。（来源：知乎问题“如何估算数据库所需存储空间？”下的高赞回答类比）

为啥没个准儿呢？数据它不是死物，它是活的，会自己“生崽”，你今天可能就十万条用户信息，觉得撑死也就几个G，但你想过没有，用户每登录一次，你可能得留条日志吧？用户每下一单，又产生一条订单记录吧？用户要是活跃，每天都能给你制造好几条甚至几十条数据，这还只是一个业务，要是再算上系统运行日志、操作记录、各种缓存数据，那数据量简直就是指数级往上窜。（来源：CSDN博客文章《数据库容量规划的血泪教训》）这就像你只算了每天买菜的钱，没算水电煤气、零食饮料、偶尔下馆子的开销,那预算能准吗？

数据它不光长个儿，它还“发福”，啥意思呢？就是单条数据占的空间可能会变，比如说，最早用户昵称你规定最多10个字，后来为了国际化，支持各种生僻字和特殊符号，字段长度改成了50个字，好家伙，这一下子，哪怕用户数没变，光昵称这一项占的空间可能就翻了五倍，再比如，产品经理一拍脑袋，说要增加一个用户个人简介的字段，允许写500字，还得能上传头像，得，每个用户的数据体积又胖了一圈，这种表结构的变更，在项目初期根本没法预料。（来源：一位后端开发工程师的经验分享）

还有啊，你以为数据存进去就完事了？太天真了，为了让你查询速度快，数据库还得建“索引”，这索引就好比一本厚厚的字典前面的拼音检字表或者部首检字表，它能帮你快速找到字，但检字表本身也占书的页码啊！数据量越大，索引占的空间也越大，有时候索引的大小甚至能占到数据本身大小的三分之一到一半，你在算空间的时候，要是只算了数据本身，把这部分给忘了，那等数据库跑起来，发现房子（硬盘）突然就不够住了。（来源：《高性能MySQL》一书中关于索引存储空间的讨论）

做项目总得留点余量，不能可丁可卯，你不能说算出来一年后大概是500G，你就真只准备个600G的硬盘，万一某个活动突然火了，数据量一天顶一个月，你怎么办？数据库满了可是要宕机的，到时候网站打不开，App闪退，损失可就大了，所以一般都会留出百分之二三十，甚至更多的“安全缓冲区”，这个缓冲区留多少，又是个经验活，留少了危险，留多了浪费，可不就是“没个准儿”么。（来源：腾讯云数据库专家在技术沙龙上的建议）

技术本身也在变，以前数据量大了，可能就想办法删掉一些旧的、不常用的数据，叫做“冷数据归档”，但现在大数据时代，大家又觉得这些数据都是宝贝，指不定哪天就能挖出金矿来，舍不得删，那怎么办？只能不停地加硬盘，从机械硬盘换到固态硬盘，从单机存储扩展到分布式存储，成本和技术复杂度都上去了，但空间需求的“准数”反而更难把握了。（来源：InfoQ对某互联网公司首席架构师的访谈）

所以你看，数据库存储空间这事儿，它不是一个简单的数学公式能算清的，它牵扯到业务增长的不确定性、需求的变化、技术实现的细节、以及对未来的风险预估，它更像是一门艺术，靠的是经验、预判和不断的调整，说到底，“准备多少才够用？”这个问题的标准答案可能就是：在你能承受的成本范围内，尽量多准备一点，并且建立一个灵活的、可以随时扩展的方案，毕竟,有备才能无患嘛。