我正在编写一个由MySQL数据库备份的Web应用程序,其中一个表有可能变得非常大(数字千兆字节),其中大部分表操作都是写入。其中一个表列需要存储一个非常大的字符串序列。在我的测试中,它已达到289字节的大小,但为了安全起见,我想设计最大尺寸为1 kb。目前我将该列存储为InnoDB表中的MySQL MediumBlob字段。
与此同时,我一直在谷歌上搜索BLOBs相对于其他存储形式的相对优缺点。那里有太多的信息,也许太多了。我收集的是InnoDB存储表行本身和其他地方的BLOB的前几个字节(如果内存服务于我,则为789)。我也有这样的想法:如果一行每列有多个BLOB(我的表没有),那么“其他”就是每个BLOB的不同位置。除此之外,我得到的印象是访问BLOB数据要比访问行数据慢得多(这听起来很合理)。
我的问题就是这个 - 根据我的BLOB大小和桌子的巨大潜在尺寸我应该打扰一下blob吗?另外,如果我使用某种形式的inrow存储而不会对该表能够容纳的最大行数产生不利影响?
MySQL非常简洁,让我可以放弃开发环境中的所有内容。但是......那不是现实世界。
答案 0 :(得分:1)
如果BLOB数据超过250kb,则不值得。在你的情况下,我不会打扰自己的BLOB'n。 Read this
答案 1 :(得分:1)
我确定你已经看过了here,但很容易忽略一些细节,因为在InnoDB限制方面需要注意很多。
您的一个问题(表的最大大小)的简单答案是64TBytes。使用可变大小类型将存储移动到单独的文件中肯定会改变行数的上限,但64TBytes的空间相当大,因此比例可能非常小。
具有1KByte字符串类型的列存储在表中似乎是一个可行的解决方案,因为它与64TBytes相比也非常小。特别是如果您对查询速度有非常严格的要求。
另外,请记住,InnoDB 64TByte限制可能会被您正在使用的操作系统的最大文件大小压低。您可以随时将多个文件链接在一起以获得更多的桌面空间,但随后它开始变得更加混乱。