"долгая вставка индекса первичного ключа" - это как бы сказки. Или, если на самом деле тормозит - то весьма вряд ли по вине MySQL, там же посредников не счесть.
Сортировка и группировка выполняется не по таблицам, а по выражениям. Но это к слову.
"сортируемые и группируемые поля добавить в самый конец индекса" ?? Какого индекса-то? не говоря уж о том, что индексов по выражениям, включающим поля нескольких таблиц - не существует. Не только в MySQL - вообще в любой СУБД.
Естественно это настройки сервера, в частности выделение памяти под временные таблицы, чтобы их тип был инмемори, а не диск. Нужен баланс между доступной памятью и выделенной под оптимизацию запросов в памяти. Кэш запросов, индексов, временные таблицы - все это желательно поместить в память.
Составной индекс если будут использоваться много полей, и отдельные если каждое из полей будет одиночной сортировкой.
Например на сайте новостей 1 секунда это много, а на приложении с миллиардами записей статистики по мировым продажам жвачки в розницу для планирования расширения сети продаж с 30 объединениями/группировками/дистинкт выборками надцать секунд или даже минут это норм, так как задача другая совершенно.
а explain подскажет где можно подкрутить что-то на уровне индексов/памяти, код при этом вообще не трогается. Да и по большому счету 99% типовых задач не пишутся руками, а пускаются через модель/орм.
Если вам нужен именно конкретный запрос с конкретным набором выходных данных, менять вы его не будете, логично что крутить вы можете только структуры данных и индексы, ну может еще что-то в настройках самого сервера.