我从MysqlTunner.pl得到这个消息：
join_buffer_size> = 4 M这不build议
另一方面，我读了Debian关于jont_buffer_size的my.cnf指南：
此缓冲区用于优化完整JOIN（没有索引的JOIN）。 在大多数情况下，这样的JOIN对性能来说是非常糟糕的，但是将这个variables设置为一个较大的值会降低对性能的影响。 请参阅“Select_full_join”状态variables以查看完整JOIN的计数。 如果find完全连接，则为每个线程分配一个线程
所以我想知道我应该相信哪一个？ 目前我已经设置了join_buffer_size = 64M，作为应对高stream量站点的可扩展性问题的一部分，其中查询并不是特别优化的。 我很欣赏你的提示。
join_buffer_size = 64MB是有点疯狂，这是+ 64MB分配给每个新的线程。
用于普通索引扫描，范围索引扫描和不使用索引的连接的缓冲区的大小，从而执行全表扫描。 通常，获得快速连接的最佳方式是添加索引。 增加join_buffer_size的值可以在添加索引时获得更快的完全连接。
我想说，你应该减lessjoin_buffer_size到128K和256K之间的值，同时增加索引到你的表，并使用刚刚保存的内存来增加key_buffer_size > + 10倍。
更多的内存并不总是转化为更快的速度，常见的例子有： read_rnd_buffer_size ， read_buffer_size ， read_rnd_buffer_size和table_open_cache 。 去谷歌上查询。
他们似乎都对我说同样的话。 他们都告诉你， 全联接是坏的 。
你检查了Select_full_joinvariables吗？ 你真的看到这个反增长？ 你确定修复代码或者向负责修复的人大喊大叫是不是一种select？
并非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×150个连接。 十多年来，默认值保持在128K。 增加默认值不仅浪费服务器内存，而且往往不利于性能。 在几乎所有情况下，最好通过删除或注释掉这四个缓冲区configuration行来使用默认值。 对于更渐进的方法，将它们减半以释放浪费的RAM，随着时间的推移将它们降低到默认值。 实际上我已经通过减less这些缓冲区来提高吞吐量。 但是，除非在高stream量和/或其他特殊情况下，增加这些缓冲区确实没有性能收益。 避免任意增加这些！
与通用逻辑相反，访问内存不是O（1）。
你有更多的RAM，更慢的是访问这个RAM中的任何数据。
所以，使用更less的RAM实际上可以提供更快的RAM访问 – 这是一个通用规则，不仅适用于MySQL。 请看RAM的神话 – 为什么随机存储器读取是O（√N）
现在让我们回到MySQL join_buffer_size。
join_buffer_size分配给两个表之间的每个完整联接。 从MySQL的文档中，join_buffer_size被描述为：“用于普通索引扫描，范围索引扫描和不使用索引并因此执行全表扫描的连接的最小大小”。它继续说：“如果全局大小大于大多数使用它的查询所需的内存分配时间，则会导致性能下降。“当连接不能使用索引时，连接缓冲区将分配给caching表行。 如果你的数据库受到很多没有索引的连接，那么只需增加join_buffer_size即可解决。 问题是“没有索引的连接”，因此加快连接的解决scheme是添加索引。
将MySQLconfiguration更改为logging没有索引的查询，这样您将能够find这样的查询并添加索引和/或修改发送生成此类不良查询的应用程序。 您应该启用“log-queries-not-using-indexes”，然后在慢查询日志中查找非索引连接。
我不这么认为。 它的可能mysqltunerbuild议您configuration您可能需要的configuration。 如果我在DB服务器上运行mysqltuner。 这里是build议我得到：
Variables to adjust: *** MySQL's maximum memory usage is dangerously high *** *** Add RAM before increasing MySQL buffer variables *** join_buffer_size (> 64.0M, or always use indexes with joins) innodb_buffer_pool_size (>= 54G) if possible. innodb_log_file_size should be (=2G) if possible, so InnoDB total log files size equals to 25% of buffer pool size.
所以我认为在另一台服务器上并不总是不好的尺寸。
没有INDEXES的连接应通过分析和适当的索引创build来解决。
使用mysqlcalculator.com和你的join_buffer_size来查看内存需求的影响。 应该花费不到1分钟的时间来取得戏剧性的结果。