Você está usando um design EAV e tentando reconstruir uma única linha de um número variável de atributos. Isso aponta para uma das muitas minas terrestres que você encontrará usando o design EAV:há um limite prático no número de junções que você pode fazer em uma única consulta SQL.

Especialmente no MySQL -- há um limite rígido, como você descobriu. Mas mesmo em outras marcas de RDBMS, há um limite efetivo porque o custo das junções é geométrico em relação ao número de tabelas.

Se você usa EAV, não tente reconstruir uma linha no SQL como se você tivesse um design de banco de dados convencional. Em vez disso, busque os atributos como linhas, classificadas pelo ID da entidade. Em seguida, processe-os posteriormente no código do aplicativo. Isso significa que você não pode despejar os dados em uma etapa - você precisa escrever código para fazer um loop nas linhas de atributos e reformar cada linha de dados antes de poder produzi-los.

O EAV não é um design de banco de dados conveniente. Existem muitas desvantagens caras em usá-lo, e você acabou de acertar uma delas.

Veja http://www.simple-talk.com/opinion /opinion-pieces/bad-carma/ para uma ótima história sobre como o uso de EAV condenou um negócio.

E também veja http://en.wikipedia.org/wiki/Inner-platform_effect porque o EAV é um exemplo desse antipadrão.

Eu entendo a necessidade de oferecer suporte a um conjunto dinâmico de atributos por produto em um catálogo. Mas o EAV vai matar seu aplicativo. Aqui está o que eu faço para dar suporte a atributos dinâmicos:

• 
  Defina uma coluna real na tabela base para cada atributo comum a todos os tipos de produto. Nome do produto, preço, quantidade em estoque, etc. Trabalhe duro para imaginar o produto canônico entidade para que você possa incluir o maior número possível de atributos neste conjunto.
  
• 
  Defina mais uma coluna do tipo TEXT para todos os atributos adicionais de cada tipo de produto. Armazene nesta coluna como LOB serializado dos atributos, em qualquer formato que lhe agrade:XML, JSON, YAML, seu próprio DSL caseiro, etc.
  
  Trate isso como uma única coluna em suas consultas SQL. Qualquer pesquisa, classificação ou exibição que você precise fazer com base nesses atributos exige que você busque todo o TEXT blob em seu aplicativo, desserialize-o e analise os atributos usando o código do aplicativo.