MySql 中的性能瓶颈：行数或文件大小？答案

【问题标题】：Performance bottleneck in MySql: number of rows or size of file?MySql 中的性能瓶颈：行数或文件大小？
【发布时间】：2017-09-06 13:01:02
【问题描述】：

我正在使用 MySQL 数据库构建应用程序。我只有一张表格：

     Key    | Metadata  | Data
------------+-----------+-----------
  Some GUID | Some info | large data

元数据是一堆小列，如 DateTime、VarChar(8) 等。数据列是一个长文本列，通常包含 250kb 的文本（但最多可以包含几兆字节的文本）。我只使用密钥进行查找（从不扫描元数据或数据）并且密钥没有排序。我很少删除。

这张表是否可以很好地扩展？ IE。是否能够轻松处理超过 100000 行？

我知道 100000 行对于一个表来说是一个很小的数字，但表文件可能会占用 25gb，所以这有点大。

我的直觉是它应该工作得很好，因为索引将允许 MySQL 快速到达它需要返回/编辑的行，但我不确定表的大小。

这不是一个开放式问题：我正在寻找的答案是：会好或不会好，并解释原因。

【问题讨论】：

【解决方案1】：

这都是关于 I/O 的。而且你有很多问题正在密谋反对你。

多少内存？ innodb_buffer_pool_size 的值是多少？（我假设表是 InnoDB？）
GUID 很糟糕，因为它们具有随机性。见http://mysql.rjweb.org/doc.php/uuid
250KB 的文本将被“非记录”存储，需要至少一个额外的磁盘命中才能获取它。
考虑压缩LONGTEXT 列。如果是英文文本、代码或者XML，压缩比大概是3:1。在客户端进行压缩/解压。然后使用LONGBLOB 而不是LONGTEXT。更小 -> 更多可缓存 -> 更少 I/O -> 更快。

把东西放在一起，我看到了：

由 GUID 索引的“小”~0.1GB 表。即使您的服务器很小，这也可能可以缓存在 RAM 中。所以，没问题。而且我关于 GUID 的链接并不那么相关，只是它有助于解释一些事情。
因此，一旦事情升温（0.1GB 大部分已加载），主要时间是从磁盘获取 LONGTEXT - 它不太可能被缓存。
LONGTEXT 将在别处，但您一次只能获取一个。
在 250 KB 时，将有很多磁盘命中。
如果它被压缩（在客户端），那么 I/O 是 1/3。也就是说，压缩是性能的主要修复。但您只能获得 3 倍的加速。

您将如何处理该文档？如果您正在提供网页，请考虑将它们存储为文件，然后单击直接转到 fs.这通常是对图像的建议。

【讨论】：