Поскольку вопрос не содержит требования корректности сетевой конфигурации, то он не устанавливает невозможности иметь несколько узлов с одним и тем же адресом. Да, работать (во всяком случае нормально) не будет, но требование-то выполнено.
хотя по счет динамических атрибутов не совсем понял
Что там непонятного? Есть более двух десятков возможных имён атрибутов. И какие из них будут у случайно выбранного узла - определить невозможно. Даже зная часть имён атрибутов, невозможно указать их полный список.
Ну тогда остаётся только жалеть, что не было сделано профилирование. Почти наверняка там были 99% на Send data - то есть, на знатные тормоза со стороны дисковой подсистемы.
Adamos, очень важно - изменился ли EXPLAIN после того, как ТП там что-то подрихтовала?
Если EXPLAIN изменился (что, кстати, вполне вероятно), то запрос всё же требует оптимизации. Пока статистика на вашей стороне - но если её перекосит, можно запросто опять уйти в область неоптимального плана выполнения.
Если нет - то причина 99% лежит за пределами MySQL. И я бы лично с большим пристрастием пытал бы ТП до тех пор, пока не получил полные сведения по причине, мотивируя необходимостью знать как симптомы и возможную причину проблемы, так и способ её устранения. Понятно, что ТП будет всеми силами стараться ничего не сказать - кому ж хочется признаваться в собственном косяке?
По сути показанные данные - это типичный лес с динамическими атрибутами листьев. Наиболее соответствующая структура хранения - Parent-Child EAV.
Поскольку привязка динамических данных к точкам потребления в программе тупо хардкодится, других проблем не вижу.
Здесь нет ничего сложного. Достаточно внимательно прочитать учебник по группировке и агрегатным функциям, обратив особое внимание на правило "или в выражении группировки, или в аргументе агрегатной функции".