我不久前接手了一个项目，其中文件二进制文件存储为BLOB。那些是0.5-50 Mb的大小，因此该表被尽可能少地触摸（ - > eBeans延迟加载等）。只要整个系统在一个专用服务器上运行，BLOB的工作就很好了，一旦我们切换到AWS EC2实例+ RDS，事情（显然）就慢了。
因此，我将数据存储从BLOB切换到S3（+对存储在数据库中的存储桶/密钥的引用），这对我们的后端和客户来说要快得多。
现在我的问题是，显然程序员在设置mySQL数据库之前处理更大的数据块（最大包大小等），我也偶然发现了一些关于连接池大小的讨论。
在mySQL设置中检查哪些关键参数，以及评估它们的有效方法是什么？
答案 0 :(得分：1)
您问题的最可能答案是＆＃34;什么都不做。＆＃34;
MySQL有很多很多很多可调整的＆＃34;参数，网上有很多关于＆＃34;优化＆＃34;他们。但这是最好避免的诱惑。
如果系统变量已从默认值更改，如果您发现自己处于需要调整配置的情况，那么首先本能应该将设置恢复为默认值除非你有特定和合理的理由不这样做。
设置为max_allowed_packet的设置如果设置得太小，会打破一些东西（比如大blob）但是如果设置大于必要则会产生很少或没有影响...＆＃34;多余＆＃34;没有分配或有害。在max_allowed_packet的情况下，这确实通过限制服务器需要为单个数据包分配的内存量来限制内存使用，但由于它是一个砖墙限制，你不要＃＆＃ 39;一定要缩小它。如果你发送的数据包不大，那就不会有任何伤害。
增加此变量的值是安全的，因为仅在需要时才分配额外的内存。例如，mysqld仅在发出长查询或mysqld必须返回大结果行时才分配更多内存。变量的小默认值是在客户端和服务器之间捕获不正确的数据包的预防措施，也是为了确保您不会意外地使用大数据包而耗尽内存。
http://dev.mysql.com/doc/refman/5.7/en/packet-too-large.html
但是，其他参数可能具有显着的反直觉negative effects，因为＆＃34;有效＆＃34;值是＆＃34;最佳＆＃34;范围的超集。值。查询缓存就是一个很好的例子。 ＆＃34;但它的缓存更多！怎么会这么糟糕？！＆＃34;好吧，一个更大的房子增加了你必须做的家务劳动量，而查询缓存是一个只有一个小扫帚的大房子（每个线程在进入和离开时都会争用的全局互斥体）。
还有一些人，比如innodb_buffer_pool_size，对于给定的服务器，只有一个相对较小的最佳值范围。太小会增加磁盘I / O并降低性能，因为池小于系统可能支持的，太大会增加磁盘I / O，因为服务器使用交换空间或者通过耗尽每个最后可用的千字节系统来完全崩溃免费RAM。
也许你明白了。
除非您认为某个特定参数可能配置不合理，否则请保持正常工作。如果您更改了内容，请一次更改一项，并在继续之前证明或反驳每项更改都是一个好主意。如果您使用的是非默认值，请将默认值视为潜在的良好候选值。
远离＆＃34;调整脚本＆＃34;提出有关您应该更改的参数的建议。这些看起来很有意思，但他们的建议往往是危险的。我经常考虑编写自己的其中一个，但它所要做的就是检查未设置为默认值的值，并告诉用户解释自己或将其设置回来。 :)也许这会流行起来。