alf*_*ish 9 mysql database buffer
我从 MysqlTunner.pl 收到此消息：
join_buffer_size >= 4 M 不建议这样做
另一方面，我在 Debian 的 my.cnf 指南中阅读了有关 jont_buffer_size 的内容：
此缓冲区用于优化完整 JOIN（没有索引的 JOIN）。在大多数情况下，这种 JOIN 对性能非常不利，但将此变量设置为较大的值会降低性能影响。有关完整 JOIN 的计数，请参阅“Select_full_join”状态变量。如果找到完全连接，则按线程分配
所以我想知道我应该相信哪一个？目前，我已将 join_buffer_size = 64M 设置为解决查询未特别优化的高流量站点的可伸缩性问题的努力的一部分。我很欣赏你在这方面的提示。
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_size和table_open_cache。去谷歌上查询。
他们似乎都在对我说同样的话。他们都告诉你FULL JOINS 是不好的。
你检查Select_full_join变量了吗？你真的看到这个计数器增加了吗？您确定修复代码或对负责修复它的人大喊大叫不是一种选择吗？
并非 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。
为两个表之间的每个完整连接分配 join_buffer_size。在 MySQL 的文档中，join_buffer_size 被描述为：“用于普通索引扫描、范围索引扫描和不使用索引并因此执行全表扫描的连接的缓冲区的最小大小。” 它接着说：“如果全局大小大于使用它的大多数查询所需的内存分配时间，则会导致性能大幅下降。” 当连接不能使用索引时，连接缓冲区被分配给缓存表行。如果您的数据库在没有索引的情况下执行了许多连接，那么仅通过增加 join_buffer_size 是无法解决的。问题是“在没有索引的情况下执行连接”，因此更快连接的解决方案是添加索引。
更改 MySQL 配置以记录没有索引的查询，因此您将能够找到此类查询并添加索引和/或修改发送生成此类错误查询的应用程序。您应该启用“log-queries-not-using-indexes”然后在慢查询日志中查找非索引连接。