从BLOB到filestorage的转换- mySQL调整

Question

不久前，我接手了一个项目，在这个项目中，文件二进制文件被存储为BLOB。这些大小为0.5~50 Mb，因此该表被尽可能少地接触(->，eBeans，lazyloading等)。只要整个系统运行在一台专用服务器上，BLOB就能很好地工作，一旦我们切换到AWS EC2实例+ RDS，事情就会(显然)慢一些。

因此，我将数据存储从BLOB转换为S3 (+引用存储在DB中的桶/键)，这对于后端和客户端来说要快得多。

现在我的问题是，很明显，在设置mySQL DB以处理更大的数据块(最大包大小等)之前，程序员可能会遇到一些关于连接池大小的讨论。

在mySQL设置中检查哪些关键参数，以及评估它们的有效方法是什么？

Answer 1

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

MySQL有很多，很多，很多“可调”参数，网上有大量关于“优化”这些参数的坏建议。但这是最好避免的诱惑。

如果系统变量已经从默认状态更改，如果您发现自己遇到了需要调整配置的情况，那么您的第一反应应该是将设置还原为默认设置，除非您有特定和合理的理由不这样做。

如果设置得太小，像max_allowed_packet这样的设置会破坏某些东西(如大气泡)，但如果设置得比必要的大，则会产生很少或没有影响.“超额”不是分配的，也不是有害的。在max_allowed_packet的情况下，这确实通过限制服务器为单个数据包分配的内存量来对内存使用施加限制，但是由于这是一个砖墙限制，所以不一定要收缩它。如果你没有发送那么大的数据包，它不会伤害任何东西。

增加此变量的值是安全的，因为只有在需要时才会分配额外的内存。例如，mysqld只在发出长查询或mysqld必须返回大结果行时才分配更多内存。变量的小默认值是一种预防措施，可以在客户端和服务器之间捕获不正确的数据包，并确保您不会意外地使用大数据包而耗尽内存。 http://dev.mysql.com/doc/refman/5.7/en/packet-too-large.html

但是，其他参数可以具有显着的反直觉负面效应，因为“有效”值的范围是“最优”值范围的超集。查询缓存就是一个很好的例子。“但它的缓存更多了！这怎么可能是坏事呢？”好吧，更大的房子会增加你必须做的家务，查询缓存是一个大房子，只有一个小扫帚(每个线程在进出时都会争夺一个全局互斥物)。

还有一些，如innodb_buffer_pool_size，对于给定的服务器，实际上只有一个相对较小的最优值范围。太小会增加磁盘I/O并损害性能，因为池比系统所能支持的要小；过大会增加磁盘I/O，这是由于服务器使用交换空间，或者通过耗尽每一个可用的最后一千字节的空闲RAM而使其崩溃。

也许你知道这个主意。

除非您有一个您认为可能是次优化配置的特定参数，否则请让工作系统正常工作。如果你改变了事情，一次一个地改变它们，并且在继续之前证明或否定每一个改变都是一个好主意。如果使用的是非默认值，请将默认值视为潜在的良好候选值。

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