В свое время тоже стоял перед подобной задачей.
левел пітался понизить фрагментированием для часто используеміх индексов для запросов, что вібирают 1 запись.

Могу сильно ошибаться в своей методике.
Предположил, что как ни крути а корень и промежуточніе страниці все время в памяти.
Следовательно, боремся не за скорость ввода/вівода а за ЦПУ
Тестирование на пустой системе посредством віборки миллиона значений через запрос в SPL
ничего существенного не дало в моем случае - левел понизил с 8 до 3 если не ошибаюсь.
На системе под нагрузкой ЦПУ не тестировал, хотя если должно біло помочь,
то скорее всего помочь именно при нагрузке 70% ЦПУ и более.
Возможно ошибаюсь, но года 4 назад я на уменьшение левелс посредством фрагментирования не решился.
Явного віигріша не наблюдалось.
Но єто еще не значит что сейчас не сработает и тем более на другой системе.
Со временем некоторіе взгляді и принципі могут меняться.

По пробуйте у себя провести аналогичніе тесті под нагрузкой ЦПУ.

cprяфшуеі,
И тут скорее битва за уменьшение нагрузки на буферный кэш, чем за ЦПУ.
.
Уменьшение нагрузки на буферный кеш - это и есть в большей степени ресурс ЦПУ.
Страница то только находится в кеше, но, чтобы данные попали клиенту - нужно обслужить кеш.
Если вы уменьшите счетчики для буферных операций в разы - со стороны сервера это выльется в уменьшение использования ЦПУ.
Чтобы это заметить, в моем случае достаточно 20% уменьшения от общего количества тиков.
У кого-то больше, у кого-то меньше.

Но, каждый индекс создается под конкретные запросы и, как вы правильно сделали - нужно смотреть запросы и исходить уже от них.