O mesmo MySQL consulta um com índice segundo sem obter o tempo de 10000xFetch?

OR UPPER(lu.opis) LIKE UPPER('%SomeName%')

tem 3 problemas de desempenho:

OR está mal otimizado. Essencialmente, a tabela deve ser verificada para verificar todas as linhas. É improvável que os índices ajudem.
UPPER(indexed-column) impede o uso de um índice nessa coluna. Isso é facilmente resolvido ao declarar que a coluna tem um COLLATION que não diferencia maiúsculas de minúsculas, ou seja, algo como utf8_unicode_ci; observe o _ci .
LIKE '%... não pode usar um índice por causa do principal curinga.

Além disso, geralmente é tolice ter

32497 row(s) returned

O que você vai fazer com tantas linhas? O tempo de transferência da rede será significativo, mesmo que a consulta em si não seja.

Para "resolver" o LIKE , OR , e UPPER problemas de uma só vez, reúna o texto em uma única coluna em uma única tabela. Em seguida, forneça um FULLTEXT índice nessa coluna. O, MATCH ... AGAINST ... rodará muito mais rápido -- pelo menos para fazer o SomeName procurar. (Os LEFT JOINs são outra coisa.)