Помогите в настройке MySQL

max_heap_table_size = 512M

tmp_table_size = 1024M

эти значения в 99% должны быть одинаковы, попробуйте поставить 1024M и там и там или даже увеличить до 1536M , если свободной памяти много (мускул и так у Вас больше 50% жрет)

key_buffer_size = 1024M

хватит и 128M, у Вас все индексы не больше 50

sort_buffer_size = 64K

попробуйте поднять до 256K

table_cache = 2000

Исходя из тюнера - достаточно и 1000 вполне

или даже

sort_buffer_size = 64K

read_buffer_size = 256K

read_rnd_buffer_size = 256K

все 3 значения поподнимать потихоньку (без лишнего энтузиазма), 256K => 384K => 512K и посмотреть на результат.

Вообще судя по Slow queries: 0% - у Вас не так все плохо, но если проблема есть (а не ради эстетства), то включите слоу_квери_лог и посмотрите какие запросы тормозят, и попробуйте их как раз и оптимизировать. Одними настройками my.cnf не всегда можно решить вопрос полностью.

какой неверный подход к оптимизации СУБД

нужно смотреть запросы и из этого исходить, какие параметры подымать

использовании временных таблиц - это плохой тон!

Не надо ее бороть. Это особенность исполнения некоторых типов запросов. mysqltuner не может отличить вынужденные создания маленьких файлов на диске и случаи, когда не хватает памяти.

Увеличивай параметр и следи за динамикой изменения показателя. Если перестал улучшаться - дальше смысла нет гнать. Если грубо, то пожалуй на 64мб можно уже остановиться.

Вот перетащить временный каталог /tmp в tmpfs имеет смысл.

использование временных таблиц не дурной тон, а нормальная практика в написании высокороизводительных запросов со сложной логикой

во-первых, временные таблицы сервер постоянно создает сам - если запрос чуть сложнее чем select * from table

во-вторых, использование промежуточных временных таблиц обычно ускоряет выполнение сложных запросов - все-таки компилятор SQL весьма далек от совершенства и зачастую приходится ему помогать, как раз через создание промежуточных временных таблиц

Это симптомы кривого движка, программист которого не утруждал себя оптимизацией запросов к SQL.

Тюнингом ничего не сделать - надо править запросы.

Ни в коем случае не следуйте этому совету, разве что у вас хранилище на десятки САС дисков, огромный кеш на запись и фиброй оно включено прямо в сервер. При работе с такого объема временными файлами у вас просядет сервер по производительности так, что вы не поймете в чем дело. Разбираться в первую очередь с запросами (особенно с select * from...), индексами, джойнами, форинкеями. Поставьте ограничение на количество записей в выборке (max_join_size) и смотрите в ошибки - выясняйте какой запрос убивает базу (возможна рекурсия или неправильное связывание таблиц).