Forneça
SHOW CREATE TABLE . Espero ver esses índices compostos:
`val`: (entityId, attributeId) -- order is not critical
Infelizmente, porque
code é LONGTEXT , isso não é possível para entity :INDEX(type, code, entityId) . Portanto, isso não será muito eficiente: SELECT entityId
from entity
where code = v9.Value
and type = 97
limit 1
Vejo
LIMIT com um ORDER BY -- você se importa com o valor que você recebe? Provavelmente isso seria melhor escrito como
WHERE EXISTS ( SELECT 1 FROM entity
WHERE entityID = e3.entityID
AND code = v9.Value
AND type = 97 )
(Você tem certeza sobre a mistura de
e3 e v9 ?) Invólucro...
Isso força o
LEFT JOIN para se tornar JOIN . E ele se livra do ORDER BY interno então . Então o Otimizador provavelmente decide que é melhor começar com
68e9145e-43eb-4581-9727-4212be41bef5 , que chamo de val AS v11 :JOIN val AS v11 ON (v11.entityId = e2.id
and v11.attributeId = 1614)
AND v11.Value = 'bar2')
Se esta for uma tabela EAV, tudo o que ela faz é verificar se [, 1514] tem o valor 'bar2'. Isso não parece um teste sensato.
além da minha recomendação anterior.
Eu preferiria
EXPLAIN SELECT ... . EAV
Assumindo
val é uma tabela EAV tradicional, isso provavelmente seria muito melhor:CREATE TABLE `val` (
`attributeId` int(11) NOT NULL,
`entityId` int(11) NOT NULL,
`Value` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
PRIMARY KEY(`entityId`,`attributeId`),
KEY `IX_val_attributeId` (`attributeId`),
) ENGINE=InnoDB AUTO_INCREMENT=2325375 DEFAULT CHARSET=latin1
Os dois IDs não têm uso prático (a menos que esteja faltando alguma coisa). Se você for forçado a usá-los por causa de uma estrutura, isso é lamentável. Promover (entityId, attributeId) para ser o PK faz a busca de
value um pouco mais rápido. Não há nenhuma maneira útil de incluir um
LONGTEXT em qualquer índice, então algumas das minhas sugestões anteriores precisam ser alteradas. 
