问join_buffer_size >= 4M不建议吗？

EN

join_buffer_size =64 to有点疯狂，即分配给每个新线程的+64 to。

用于普通索引扫描、范围索引扫描和不使用索引从而执行全表扫描的联接的缓冲区的大小。通常，获得快速连接的最佳方法是添加索引。当不可能添加索引时，增加join_buffer_size的值以获得更快的完全连接。

我想说的是，您应该将join_buffer_size简化为128K和256K之间的值，同时将索引添加到表中，并使用刚才保存的内存来增加key_buffer_size >+10倍。

更多的内存并不总是转化为更快、更常见的例子：sort_buffer_size、read_buffer_size、read_rnd_buffer_size和table_open_cache。用谷歌搜索。

不增加每个连接缓冲区！

并非my.cnf中的所有缓冲区只为服务器实例分配一次。为每个连接分配一些缓冲区。请在https://haydenjames.io/my-cnf-tuning-avoid-this-common-pitfall/上查看更多信息：

引用：

每个连接都分配诸如join_buffer_size、sort_buffer_size、read_buffer_size和read_rnd_buffer_size之类的缓冲区。因此，read_buffer_size=1M和max_connections=150的设置要求MySQL为每个连接x150个连接分配-从启动到1MB的连接。十多年来，违约率一直保持在128 K。增加缺省值不仅浪费服务器内存，而且常常无助于性能的提高。在几乎所有情况下，最好通过删除或注释掉这四个缓冲区配置行来使用默认值。对于一种更渐进的方法，将它们减少一半以释放浪费的RAM，并随着时间的推移将它们减少到默认值。实际上，通过减少这些缓冲区，我看到了更高的吞吐量。但是，增加这些缓冲区并没有提高性能，除非在非常高的流量和/或其他特殊情况下。避免任意增加这些！

内存访问速度

与普通逻辑相反，内存访问不是O(1)。

您拥有的RAM越多，访问该RAM中任何数据的速度就越慢。

因此，使用较少的RAM可以提供对RAM的更快访问--这是一个普遍的规则，不仅适用于MySQL。请参阅内存的神话-为什么随机存储器读取是O(√N)

现在让我们回到MySQL join_buffer_size。

调谐MySQL join_buffer_size

join_buffer_size分配给两个表之间的每个完全连接。从MySQL的文档中，join_buffer_size被描述为：“用于普通索引扫描、范围索引扫描和不使用索引从而执行完整表扫描的联接的缓冲区的最小大小。”它接着说：“如果全局大小大于大多数使用内存的查询所需的大小，内存分配时间可能会导致性能大幅下降。”当联接不能使用索引时，连接缓冲区被分配给缓存表行。如果您的数据库(S)遇到了许多没有索引而执行的联接，那么就不能仅仅通过增加join_buffer_size来解决。问题是“在没有索引的情况下执行的联接”，因此，更快的联接的解决方案是添加索引。

将MySQL配置更改为在没有索引的情况下记录查询，这样您就能够找到这样的查询，并添加索引和/或修改发送的应用程序来生成这样的错误查询。您应该启用“日志查询-不使用索引”，然后在慢速查询日志中查找非索引连接。

他们俩好像都在对我说同样的话。他们都在告诉你完整的加入是不好的。

• Mysqltuner指出，系统的某些地方是坏的，在这种情况下，必须有一个大的连接缓冲区是数据库有问题的迹象。
• 文档告诉您这是不好的，但是如果您不能更改代码，那么添加更多的内存将允许您接受错误。

你检查过Select_full_join变量了吗？你真的看到这个反增长了吗？你确定修改代码或对负责修复代码的人大喊大叫不是一种选择吗？