我从 MysqlTunner.pl 收到此消息：
join_buffer_size >= 4 M 不建议这么做
另一方面，我在 Debian 的 my.cnf 指南中读到有关 jont_buffer_size 的内容：
此缓冲区用于优化完整 JOIN（无索引的 JOIN）。无论如何，在大多数情况下，此类 JOIN 对性能非常不利，但将此变量设置为较大的值可以降低性能影响。请参阅“Select_full_join”状态变量以了解完整 JOIN 的数量。如果发现完整连接，则按线程分配
所以我想知道我应该相信哪一个？目前我已将 join_buffer_size = 64M 设置为努力解决高流量站点的可扩展性问题，该站点的查询没有特别优化。我很感谢您对此的提示。
答案1
join_buffer_size= 64MB 有点疯狂，也就是说为每个新线程分配了 +64MB。
用于普通索引扫描、范围索引扫描和不使用索引并因此执行全表扫描的连接所用的缓冲区大小。通常，实现快速连接的最佳方法是添加索引。当无法添加索引时，增加 join_buffer_size 的值可实现更快的全连接。
我想说，您应该将join_buffer_size值减少到和之间128K，256K同时向您的表添加索引，并使用刚刚节省的内存来增加key_buffer_size> +10x。
更多的内存并不一定意味着更快的速度，常见的例子：，，和sort_buffer_size。read_buffer_size谷歌搜索。read_rnd_buffer_sizetable_open_cache
答案2
不要增加每个连接的缓冲区！
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 从启动时起为每个连接分配 1MB x 150 个连接。十多年来，默认值一直是 128K。增加默认值不仅浪费服务器内存，而且往往对性能没有帮助。在几乎所有情况下，最好通过删除或注释掉这四个缓冲区配置行来使用默认值。对于更循序渐进的方法，将它们减少一半以释放浪费的 RAM，并随着时间的推移不断将它们减少到默认值。实际上，我已经看到通过减少这些缓冲区可以提高吞吐量。但除非流量非常大和/或其他特殊情况，否则增加这些缓冲区实际上并不会带来任何性能提升。避免任意增加这些！
内存访问速度
与常见逻辑相反，内存访问不是 O(1)。
RAM 越多，访问 RAM 中任何数据的速度就越慢。
因此，使用较少的 RAM 可能会提供更快的 RAM 访问速度 - 这是一般规则，不仅适用于 MySQL。请参阅RAM 的神话 - 为什么随机内存读取是 O(√N)
现在让我们回到 MySQL join_buffer_size。
调整 MySQL join_buffer_size
join_buffer_size 是为两个表之间的每个完全连接分配的。根据 MySQL 的文档，join_buffer_size 的描述为：“用于普通索引扫描、范围索引扫描和不使用索引从而执行全表扫描的连接所使用的缓冲区的最小大小。”它继续说道：“如果全局大小大于使用它的大多数查询所需的大小，则内存分配时间可能会导致性能大幅下降。”当连接不能使用索引时，将分配连接缓冲区来缓存表行。如果您的数据库遭受许多没有索引的连接，那么仅增加 join_buffer_size 是无法解决问题的。问题在于“没有索引的连接”，因此更快连接的解决方案是添加索引。
更改 MySQL 配置以记录没有索引的查询，这样您将能够找到此类查询并添加索引和/或修改发送生成此类不良查询的应用程序。您应该启用“log-queries-not-using-indexes”，然后在慢速查询日志中查找非索引连接。
答案3
他们俩似乎都在对我说同样的话。他们都在告诉你完全连接不好。
- Mysqltuner 指出您的系统存在问题，在这种情况下，必须拥有较大的连接缓冲区，这表明您的数据库存在问题。
- 文档告诉您它不好，但如果您无法更改代码，那么添加更多内存将让您接受这种不好。
你检查过Select_full_join变量了吗？你真的看到这个计数器增加了吗？你确定修复代码或对负责修复代码的人大喊大叫不是一个选择吗？
答案4
没有索引的连接应该通过分析和适当的索引创建来解决。
使用 mysqlcalculator.com 和 join_buffer_size 来查看对内存需求的影响。只需不到 1 分钟的时间就能看到显著的效果。