join_buffer_size> = 4 М не рекомендуется?

They both seem to be saying the same thing to me. They are both telling you that FULL JOINS are BAD.

• Mysqltuner is pointing out that something about your system is bad, in this case having to a have large join buffer is a sign that you have something bad about your database.
• The documentation is telling you that it is bad, but if you cannot change your code, then adding more memory will let you accept the badness.

Did you check the Select_full_join variable? Are you actually seeing this counter increase? Are you sure fixing the code or yelling at the people responsible for fixing it is not an option?

join_buffer_size = 64 МБ - это какое-то безумие, это + 64 МБ выделено каждому новому потоку.

Размер буфера, который используется для простого сканирование индекса, индекс диапазона сканирования и объединения, которые не используют индексы и, таким образом, выполняют полную таблицу scans. Normally, the best way to get fast joins is to add indexes. Increase the value of join_buffer_size to get a faster full join when adding indexes is not possible.

I'd say, you should reduce join_buffer_size to a value between 128K and 256K while adding indexes to your tables and using the memory you just saved to increase key_buffer_size > +10x.

More memory doesn't always translate to more speed, common examples: sort_buffer_size, read_buffer_size, read_rnd_buffer_size and table_open_cache. Google it.

Не увеличивайте буферы для каждого подключения!

Не все буферы в 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 выделения - с момента запуска - 1 МБ на каждое соединение x 150 соединений. Более десяти лет значение по умолчанию составляет 128 КБ. Увеличение значения по умолчанию - это не только напрасная трата памяти сервера, но и часто не способствует повышению производительности. Почти во всех случаях лучше всего использовать значения по умолчанию, удалив или закомментировав эти четыре строки конфигурации буфера. Для более постепенного подхода уменьшите их вдвое, чтобы освободить потраченную впустую оперативную память, и постепенно уменьшайте их до значений по умолчанию. Я действительно заметил улучшение пропускной способности за счет уменьшения этих буферов. Но на самом деле нет никакого увеличения производительности от увеличения этих буферов, за исключением случаев очень высокого трафика и / или других особых обстоятельств. Избегайте их произвольного увеличения!

Скорость доступа к памяти

В отличие от общепринятой логики, доступ к памяти не является O (1).

Чем больше у вас ОЗУ, тем медленнее доступ к любым данным в этой ОЗУ.

Таким образом, использование меньшего количества ОЗУ может фактически обеспечить более быстрый доступ к ОЗУ - это общее правило, применимое не только к MySQL. См. Миф о RAM - почему случайное чтение из памяти составляет O (√N)

Теперь вернемся к MySQL join_buffer_size.

Настройка MySQL join_buffer_size

Размер join_buffer_size выделяется для каждого полного объединить две таблицы. В документации MySQL join_buffer_size описывается как: «Минимальный размер буфера, который используется для сканирования простого индекса, сканирования индекса диапазона и соединений, которые не используют индексы и, таким образом, выполняют полное сканирование таблицы». Далее говорится: «Время выделения памяти может привести к существенному падению производительности, если глобальный размер больше, чем требуется для большинства запросов, которые его используют». Буфер соединения выделяется для строк таблицы кеширования, когда соединение не может использовать индекс. Если ваша база данных страдает от множества соединений, выполняемых без индексов, это не может быть решено простым увеличением join_buffer_size. Проблема заключается в том, что «соединения выполняются без индексов», и, следовательно, решение для более быстрых соединений состоит в добавлении индексов.

Измените конфигурацию MySQL, чтобы регистрировать запросы без индексов, чтобы вы могли найти такие запросы и добавить индексы и / или изменить приложение, которое отправляет, генерирует такие плохие запросы. Вы должны включить "log-query-not-using-indexes" Затем поищите неиндексированные соединения в журнале медленных запросов.

СОЕДИНЕНИЯ без ИНДЕКСОВ должны быть разрешены путем анализа и создания соответствующего индекса.

Используйте mysqlcalculator.com с вашим join_buffer_size, чтобы увидеть влияние на требования к памяти. Для впечатляющего результата вам потребуется менее 1 минуты вашего времени.

Я так не думаю. скорее всего, mysqltuner предложит вам конфигурацию, основанную на тех настройках, которые вам могут понадобиться. если я запущу mysqltuner на сервере БД. вот рекомендация, которую я получу:

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.

Так что я думаю, что это не всегда плохой размер на другом сервере и потребности.

Более простое правило:Не более 1% объема оперативной памяти.