Моля, предоставете ПОКАЖЕТЕ СЪЗДАВАНЕ НА ТАБЛИЦА .
Надявам се да видя тези съставни индекси:
`val`: (entityId, attributeId) -- order is not critical
Уви, защото code е LONGTEXT , това не е възможно за entity :ИНДЕКС(тип, код, идентификатор на обект) . Следователно това няма да е много ефективно:
SELECT entityId
from entity
where code = v9.Value
and type = 97
limit 1
Виждам LIMIT с ПОРЪЧАЙ ПО -- интересува ли ви каква стойност получавате?
Вероятно това би било по-добре написано като
WHERE EXISTS ( SELECT 1 FROM entity
WHERE entityID = e3.entityID
AND code = v9.Value
AND type = 97 )
(Сигурни ли сте за сместа от e3 и v9 ?)
Опаковане...
Това принуждава LEFT JOIN за да станете JIN . И се отървава от тогавашния вътрешен ORDER BY .
Тогава оптимизаторът вероятно решава, че е най-добре да започне с 68e9145e-43eb-4581-9727-4212be41bef5 , което наричам val AS v11 :
JOIN val AS v11 ON (v11.entityId = e2.id
and v11.attributeId = 1614)
AND v11.Value = 'bar2')
Ако това е EAV таблица, тогава всичко, което прави, е да провери дали [, 1514] има стойност 'bar2'. Това не изглежда като разумен тест.
в допълнение към предишната ми препоръка.
Бих предпочел EXPLAIN SELECT ... .
EAV
Приемайки val е традиционна EAV таблица, това вероятно би било много по-добре:
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
Двата идентификатора нямат практическа полза (освен ако не пропускам нещо). Ако сте принудени да ги използвате поради рамка, това е жалко. Повишаването на (entityId, attributeId) като PK прави извличането на стойност малко по-бързо.
Няма полезен начин за включване на LONGTEXT във всеки индекс, така че някои от предишните ми предложения трябва да бъдат променени.
