mysql - 从 BLOB 更改为文件存储 - mySQL 调整

Question

我前段时间接手了一个项目，其中文件二进制文件存储为 BLOB。那些大小为 0.5-50 Mb，因此尽可能少地触及该表(-> eBeans 延迟加载等)。只要整个系统在一台专用服务器上运行，BLOB 就可以正常工作，一旦我们切换到 AWS EC2 实例 + RDS，事情(显然)变慢了。

因此，我将数据存储从 BLOB 切换到 S3(+ 引用存储在数据库中的存储桶/ key )，这对我们的后端和客户来说要快得多。

现在我的问题是，显然程序员在设置 mySQL 数据库以处理更大的数据 block (最大 packagesize 等)之前，我也偶然发现了一些关于连接池大小的讨论。

检查 mySQL 设置的关键参数是什么，评估它们的有效方法是什么？

Answer 1

您的问题最有可能的答案是“什么都不改变”。

MySQL 有很多很多“可调”参数，网上有大量关于“优化”它们的糟糕建议。但最好避免这种诱惑。

就系统变量已从默认值更改而言，如果您发现自己处于您认为有必要调整配置的情况，您的第一直觉应该是将设置恢复为默认值除非您有具体且正当的理由不这样做。

像 max_allowed_pa​​cket 这样的设置如果设置得太小，会破坏一些东西(比如大的 blob)，但如果设置得比必要的大，影响很小或没有影响……“多余”没有分配或其他有害的。在 max_allowed_pa​​cket 的情况下，这确实通过限制服务器需要为单个数据包分配的内存量来限制内存使用，但由于它是砖墙限制，因此您不需要不一定要缩小它。如果您不发送那么大的数据包，则不会造成任何伤害。

It is safe to increase the value of this variable because the extra memory is allocated only when needed. For example, mysqld allocates more memory only when you issue a long query or when mysqld must return a large result row. The small default value of the variable is a precaution to catch incorrect packets between the client and server and also to ensure that you do not run out of memory by using large packets accidentally.

http://dev.mysql.com/doc/refman/5.7/en/packet-too-large.html

但是，其他参数可能具有显着的反直觉 negative effects因为“有效”值的范围是“最佳”值范围的超集。查询缓存就是一个典型的例子。 “但它更多的是缓存!这怎么可能是坏事？!”好吧，一个更大的房子会增加你必须做的家务量，而查询缓存是一个只有一把小扫帚的大房子(每个线程在进入和离开时争用的全局互斥体)。

还有一些，比如 innodb_buffer_pool_size 对于给定的服务器来说只有一个相对较小的最佳值范围。太小会增加磁盘 I/O 并损害性能，因为池小于系统可以支持的大小，太大会增加磁盘 I/O，因为服务器使用交换空间或耗尽系统的最后一个可用千字节而使它完全崩溃可用 RAM。

也许你明白了。

除非您有一个您认为可能配置不佳的特定参数，否则请让工作系统继续工作。如果你改变了一些东西，一次改变它们，并在继续之前证明或反驳每一个改变都是一个好主意。如果您使用的是非默认值，请将默认值视为一个可能好的候选值。

并且远离那些对您应该更改的参数提出建议的“调整脚本”。这些看起来很有趣，但他们的建议往往很危险。我经常考虑编写自己的其中一个，但它所做的只是检查未设置为默认值的值，并告诉用户自行解释或将其设置回去。 :) 也许这会流行起来。