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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› MySQL 5.5 Community Server

› MySQL 5.6 Community Server

› Percona Configuration Wizard

› XtraBackup 搭建主从复制

Great Sites on MySQL

› Percona

› MySQL Performance Blog

› Severalnines

推荐管理工具

› Sequel Pro

› phpMyAdmin

推荐书目

› MySQL Cookbook

MySQL 相关项目

› MariaDB

› Drizzle

参考文档

› http://mysql-python.sourceforge.net/MySQLdb.html

这是一个创建于 1700 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

MySQL

longtext

数据库

文件

12 条回复 • 2020-04-06 04:05:30 +08:00

loading

2020-04-05 13:11:53 +08:00 via Android

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

Livid

MOD

2020-04-05 13:18:06 +08:00

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

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

loading

2020-04-05 13:27:02 +08:00 via Android

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

Livid

MOD

2020-04-05 13:30:27 +08:00

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

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

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

xiangyuecn

2020-04-05 13:40:07 +08:00

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

MeteorCat

2020-04-05 14:07:45 +08:00 via Android

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

miniyao

2020-04-05 15:13:27 +08:00

@Livid
@xiangyuecn
@MeteorCat

感谢建议！

SuperAllen

2020-04-05 15:25:36 +08:00 via Android

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

laminux29

2020-04-05 16:13:36 +08:00

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

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

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

derek80

2020-04-05 18:06:14 +08:00 via iPhone

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

xcstream

2020-04-05 23:57:34 +08:00

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

em70

2020-04-06 04:05:30 +08:00

主要 RDB 空间比 OSS 贵得多啊