mysql 存储大量文字 mysql存储长文本

转载

GhostLover 2023-06-01 09:41:37

文章标签 mysql 存储大量文字 mysql mongodb 数据 MySQL 文章分类 MySQL 数据库

mysql超长文本解决方法

条目一：

如果是创业初期，直接用最熟悉的数据库就好比如MySQL。这样的做是有好处的，就是糙快猛。创业初期，最重要的是把项目做出来并上线。业务能不能活下来还不一定呢，想太多高性能、高可靠、易运维的事都没有太大的意义。简单可靠才是最需要关注的。

条目二：

不建议使用MySQL的TEXT类型像blob和text这样的字段，名义上是为存储很大的数据而设计的类型。但这正因为如此，这跟关系数据库使用table的设计理念是冲突的。table中的每一列数据都是定长的，比如varchar(32)。但blob和text的上限太长了，MySQL不可能将它们存储在table中，因而会使用专门的外部存储区域进行存储，数据行内存储指针。这样做的其中一个结果是会导到多一次磁盘IO，性能开销比较严重。

条目三：

新闻类文本直接静态化扔Nginx或OSS就好频繁读不频繁写的新闻资讯类文本，在保存的时候，直接写成静态的html，访问的时候直接从nginx返回。这样做，不仅可以节省服务器资源，还可以利用CDN加速，把文件放到离用户最近的CDN服务器上，既便宜又快。OSS是另一个可选的方案。OSS的优势是对图片和视频存储做了大师针对性优化，比如缩放图片和视频转码。另外，几乎所有的OSS云服务都自带CDN加速服务。熟悉程度和价格可能仍然是很重要的选择因素。

条目四：

笔记类产品MongoDB可能是个不错的选择简述MongoDB的特点如下：偶尔丢数据：在开发者水平相当的情况下，MongoDB更容易鼓励开发者做出不恰当的设计从而导致数据丢失。如果你的数据特别重要（金融、交易），那么关系型数据库可能是个更好的选择。对笔记类产品吧，可能没那么疼，忍一忍就过去了。无schema：不需要预定义的schema，以文档（json, bson）形式保存数据，同一个集合（对应关系数据库的表）中的不同文档可以使用不同的结构，并支持随时向扩展任意字段。这个特点导致MongoDB特别适合存储商品参数这类名目繁多又不尽相同的参数。在在游戏、电商、社交、直播、物流等领域都能看到MongoDB的身影。当然，随之而来的问题就是如果代码结构不够清晰，很可能导致没有任何人知道数据库中存储的数据是什么格式。对接手他人代码的人员，如果不能确定文档中有哪些字段，则可能导致相当危险的结果。如果你的数据模式比较固定的话，一个变通的方案是通过protobuf这种序列化协议引入外部模式。这对笔记类产品谈不上好或者坏，毕竟笔记的主要内容是大段不需要解析的文本。单文档查询速度快：MongoDB使用BTree结构（对比MySQL使用B+Tree），针对单文档的查询做了大量节约IO的优化，因此查询速度很快，当然吃内存也是毫不含糊。修订：MongoDB使用的也是B+Tree，原来的理解有误。多表联查功能弱：笔记产品不太需要。事务功能弱：4.0以上的版本已经支持基于Replica Set的事务，但在此之前只支持单文档的原子操作。对笔记来产品来说，弱化事务的使用可以提高数据写入效率。提供全文索引，这个对笔记类搜索有用（但中文支持弱不少 = = ）。原生支持sharding（分片），升级数据库容量时分片间的数据可以自动迁移，这对海量数据的扩容简直不要太nice。