Я получаю это сообщение от MysqlTunner.pl:
join_buffer_size> = 4 M Это не рекомендуется
С другой стороны, я читал в руководстве Debian my.cnf о jont_buffer_size, которое:
Этот буфер используется для оптимизации полных JOINs (JOINs без индексов). Такие JOIN в любом случае очень плохо сказываются на производительности в большинстве случаев, но установка для этой переменной большого значения снижает влияние на производительность. См. Переменную состояния «Select_full_join» для подсчета полных JOIN. Распределяется по потоку, если найдено полное соединение
Так что мне интересно, кому мне верить? В настоящее время я установил join_buffer_size = 64M как часть усилий по решению проблемы масштабируемости сайта с высоким трафиком, запросы которого не особо оптимизированы. Я ценю ваши намеки на это.
join_buffer_size = 64 МБ - это безумие, это +64 МБ выделено на каждый новый поток.
Размер буфера, который используется для сканирования простого индекса, сканирования индекса диапазона и объединения, которое не использует индексы и, таким образом, выполняет полное сканирование таблицы. Обычно лучший способ получить быстрое объединение - это добавить индексы. Увеличьте значение 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. Поищи в Гугле.
Кажется, они оба говорят мне одно и то же. Они оба говорят вам, что ПОЛНЫЕ СОЕДИНЕНИЯ - ПЛОХО.
Вы проверили 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 выделения - с момента запуска - 1 МБ на каждое соединение x 150 соединений. Более десяти лет значение по умолчанию составляет 128 КБ. Увеличение значения по умолчанию - это не только пустая трата памяти сервера, но и часто не способствует повышению производительности. Почти во всех случаях лучше всего использовать значения по умолчанию, удалив или закомментировав эти четыре строки конфигурации буфера. Для более постепенного подхода уменьшите их вдвое, чтобы освободить потраченную впустую ОЗУ, со временем продолжайте уменьшать их до значений по умолчанию. Я действительно заметил улучшение пропускной способности за счет уменьшения этих буферов. Но на самом деле нет увеличения производительности от увеличения этих буферов, за исключением случаев очень высокого трафика и / или других особых обстоятельств. Избегайте их произвольного увеличения!
Вопреки общепринятой логике доступ к памяти - это не O (1).
Чем больше у вас ОЗУ, тем медленнее доступ к любым данным в этой ОЗУ.
Таким образом, использование меньшего количества ОЗУ может фактически обеспечить более быстрый доступ к ОЗУ - это общее правило, применимое не только к MySQL. Посмотри пожалуйста Миф об оперативной памяти - почему случайное чтение из памяти занимает O (√N)
Теперь вернемся к MySQL join_buffer_size.
Join_buffer_size выделяется для каждого полного соединения между двумя таблицами. В документации MySQL join_buffer_size описывается следующим образом: «Минимальный размер буфера, который используется для сканирования простого индекса, сканирования индекса диапазона и объединения, которое не использует индексы и, таким образом, выполняет полное сканирование таблицы». Далее говорится: «Время выделения памяти может вызвать существенное падение производительности, если глобальный размер больше, чем требуется для большинства запросов, которые его используют». Буфер соединения выделяется для строк таблицы кеширования, когда соединение не может использовать индекс. Если ваша база данных страдает от многих объединений, выполняемых без индексов, это не может быть решено простым увеличением join_buffer_size. Проблема заключается в том, что «соединения выполняются без индексов», и поэтому решение для более быстрых соединений состоит в добавлении индексов.
Измените конфигурацию MySQL, чтобы регистрировать запросы без индексов, чтобы вы могли находить такие запросы и добавлять индексы и / или изменять приложение, которое отправляет такие плохие запросы. Вы должны включить «log-query-not-using-indexes» Затем поищите неиндексированные соединения в журнале медленных запросов.
Я так не думаю. Вероятно, 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.
Так что я думаю, что это не всегда плохой размер на другом сервере и необходимости.
СОЕДИНЕНИЯ без ИНДЕКСОВ должны быть разрешены путем анализа и создания соответствующего индекса.
Используйте mysqlcalculator.com с вашим join_buffer_size, чтобы увидеть влияние на требования к памяти. Для впечатляющего результата вам потребуется менее 1 минуты вашего времени.