MySQL 存较多的 LONGTEXT，整个数据库文件大，会导致 MySQL 性能明显下降吗？

[miniyao]

在 MySQL 中存了较多的 LONGTEXT，一条记录在 10M ~ 20 M 左右，100 万条记录，可能整个数据库文件就有 10TB 大小，这数据库还跑的动吗？

[loading]

读出数据时就有明显的 io 负担，你觉得呢。

[Livid]

恢复备份和设置 slave 都会需要更长的时间。

一个优化方式是数据库里只存 ID 或者 key，然后这些数据存到一个对象存储系统里。

[loading]

@Livid 对象存储系统是不是不用考虑备份方面了，我目前还停留在文件系统+rsync

[Livid]

@loading 需要关注元信息的安全和备份。

可以这么想：对象存储系统就是一个更 robust 的云端文件系统。

而且，如果代码中依然依赖对本地文件系统的读写，那么在上 Docker / K8S 这样的系统时，就会遇到问题。

[xiangyuecn]

另外建一个专门的数据库，啥能关的设置都关掉，事务日志也不要，专门存储这种只插入不修改很少读的数据。实质上就变成了一个 key-value 存储的玩意😂 依托 mysql 备份啥的都是原来的配方 熟悉的味道😂

[MeteorCat]

查询很费时，推荐本地文件 hash 个名称，数据库放文件 hash 就行了，不过要留意重新部署的时候文件编码问题，以前到换服务器在 window 默认记事本打开再保存变成其他编码了

[miniyao]

@Livid
@xiangyuecn
@MeteorCat

感谢建议！

[SuperAllen]

如果考虑少变动的话，就参照楼上建库，精简表，优化索引。如果检索类的比较多，可以考虑抽取数据上 es

[laminux29]

你觉得为什么会跑不动呢？
列出 1 、2 、3.

通过调试与分析，这 1 、2 、3 是否真的是瓶颈？

瓶颈都找到了，除了加钱，基本上就有方法解决。

[derek80]

建议 livid 的方案。一般云厂商都有对象存储产品，自建也有 minio 等产品应对。还是比较方便的

[xcstream]

只看标题的话 我觉得不会下降 就像 10tb 的磁盘里打开一个文件 也不会很慢吧

[em70]

主要 RDB 空间比 OSS 贵得多啊