Jak zoptymalizować bardzo powolne WYBIERZ z LEFT JOIN na dużych stołach

15

Gogolowałem, samokształciłem się i szukałem rozwiązania przez wiele godzin, ale bez powodzenia. Znalazłem tutaj kilka podobnych pytań, ale nie tę sprawę.

Moje stoły:

osoby (~ 10 mln rzędów)
atrybuty (lokalizacja, wiek, ...)
linki (M: M) między osobami i atrybutami (~ 40 mln wierszy)

Pełny zrzut ~ 280 MB

Sytuacja: staram się wybrać wszystkie identyfikatory osób ( person_id) z niektórych lokalizacji ( location.attribute_value BETWEEN 3000 AND 7000), będąc płcią ( gender.attribute_value = 1), urodzonymi za kilka lat ( bornyear.attribute_value BETWEEN 1980 AND 2000) i mającymi kolor oczu ( eyecolor.attribute_value IN (2,3)).

To jest moje zapytanie, które tooks 3 ~ 4 min. i chciałbym zoptymalizować:

SELECT person_id
FROM person
    LEFT JOIN attribute location ON location.attribute_type_id = 1 AND location.person_id = person.person_id
    LEFT JOIN attribute gender ON gender.attribute_type_id = 2 AND gender.person_id = person.person_id
    LEFT JOIN attribute bornyear ON bornyear.attribute_type_id = 3 AND bornyear.person_id = person.person_id
    LEFT JOIN attribute eyecolor ON eyecolor.attribute_type_id = 4 AND eyecolor.person_id = person.person_id
WHERE 1
    AND location.attribute_value BETWEEN 3000 AND 7000
    AND gender.attribute_value = 1
    AND bornyear.attribute_value BETWEEN 1980 AND 2000
    AND eyecolor.attribute_value IN (2,3)
LIMIT 100000;

Wynik:

+-----------+
| person_id |
+-----------+
|       233 |
|       605 |
|       ... |
|   8702599 |
|   8703617 |
+-----------+
100000 rows in set (3 min 42.77 sec)

Wyjaśnij przedłużenie:

+----+-------------+----------+--------+---------------------------------------------+-----------------+---------+--------------------------+---------+----------+--------------------------+
| id | select_type | table    | type   | possible_keys                               | key             | key_len | ref                      | rows    | filtered | Extra                    |
+----+-------------+----------+--------+---------------------------------------------+-----------------+---------+--------------------------+---------+----------+--------------------------+
|  1 | SIMPLE      | bornyear | range  | attribute_type_id,attribute_value,person_id | attribute_value | 5       | NULL                     | 1265229 |   100.00 | Using where              |
|  1 | SIMPLE      | location | ref    | attribute_type_id,attribute_value,person_id | person_id       | 5       | test1.bornyear.person_id |       4 |   100.00 | Using where              |
|  1 | SIMPLE      | eyecolor | ref    | attribute_type_id,attribute_value,person_id | person_id       | 5       | test1.bornyear.person_id |       4 |   100.00 | Using where              |
|  1 | SIMPLE      | gender   | ref    | attribute_type_id,attribute_value,person_id | person_id       | 5       | test1.eyecolor.person_id |       4 |   100.00 | Using where              |
|  1 | SIMPLE      | person   | eq_ref | PRIMARY                                     | PRIMARY         | 4       | test1.location.person_id |       1 |   100.00 | Using where; Using index |
+----+-------------+----------+--------+---------------------------------------------+-----------------+---------+--------------------------+---------+----------+--------------------------+
5 rows in set, 1 warning (0.02 sec)

Profilowy:

+------------------------------+-----------+
| Status                       | Duration  |
+------------------------------+-----------+
| Sending data                 |  3.069452 |
| Waiting for query cache lock |  0.000017 |
| Sending data                 |  2.968915 |
| Waiting for query cache lock |  0.000019 |
| Sending data                 |  3.042468 |
| Waiting for query cache lock |  0.000043 |
| Sending data                 |  3.264984 |
| Waiting for query cache lock |  0.000017 |
| Sending data                 |  2.823919 |
| Waiting for query cache lock |  0.000038 |
| Sending data                 |  2.863903 |
| Waiting for query cache lock |  0.000014 |
| Sending data                 |  2.971079 |
| Waiting for query cache lock |  0.000020 |
| Sending data                 |  3.053197 |
| Waiting for query cache lock |  0.000087 |
| Sending data                 |  3.099053 |
| Waiting for query cache lock |  0.000035 |
| Sending data                 |  3.064186 |
| Waiting for query cache lock |  0.000017 |
| Sending data                 |  2.939404 |
| Waiting for query cache lock |  0.000018 |
| Sending data                 |  3.440288 |
| Waiting for query cache lock |  0.000086 |
| Sending data                 |  3.115798 |
| Waiting for query cache lock |  0.000068 |
| Sending data                 |  3.075427 |
| Waiting for query cache lock |  0.000072 |
| Sending data                 |  3.658319 |
| Waiting for query cache lock |  0.000061 |
| Sending data                 |  3.335427 |
| Waiting for query cache lock |  0.000049 |
| Sending data                 |  3.319430 |
| Waiting for query cache lock |  0.000061 |
| Sending data                 |  3.496563 |
| Waiting for query cache lock |  0.000029 |
| Sending data                 |  3.017041 |
| Waiting for query cache lock |  0.000032 |
| Sending data                 |  3.132841 |
| Waiting for query cache lock |  0.000050 |
| Sending data                 |  2.901310 |
| Waiting for query cache lock |  0.000016 |
| Sending data                 |  3.107269 |
| Waiting for query cache lock |  0.000062 |
| Sending data                 |  2.937373 |
| Waiting for query cache lock |  0.000016 |
| Sending data                 |  3.097082 |
| Waiting for query cache lock |  0.000261 |
| Sending data                 |  3.026108 |
| Waiting for query cache lock |  0.000026 |
| Sending data                 |  3.089760 |
| Waiting for query cache lock |  0.000041 |
| Sending data                 |  3.012763 |
| Waiting for query cache lock |  0.000021 |
| Sending data                 |  3.069694 |
| Waiting for query cache lock |  0.000046 |
| Sending data                 |  3.591908 |
| Waiting for query cache lock |  0.000060 |
| Sending data                 |  3.526693 |
| Waiting for query cache lock |  0.000076 |
| Sending data                 |  3.772659 |
| Waiting for query cache lock |  0.000069 |
| Sending data                 |  3.346089 |
| Waiting for query cache lock |  0.000245 |
| Sending data                 |  3.300460 |
| Waiting for query cache lock |  0.000019 |
| Sending data                 |  3.135361 |
| Waiting for query cache lock |  0.000021 |
| Sending data                 |  2.909447 |
| Waiting for query cache lock |  0.000039 |
| Sending data                 |  3.337561 |
| Waiting for query cache lock |  0.000140 |
| Sending data                 |  3.138180 |
| Waiting for query cache lock |  0.000090 |
| Sending data                 |  3.060687 |
| Waiting for query cache lock |  0.000085 |
| Sending data                 |  2.938677 |
| Waiting for query cache lock |  0.000041 |
| Sending data                 |  2.977974 |
| Waiting for query cache lock |  0.000872 |
| Sending data                 |  2.918640 |
| Waiting for query cache lock |  0.000036 |
| Sending data                 |  2.975842 |
| Waiting for query cache lock |  0.000051 |
| Sending data                 |  2.918988 |
| Waiting for query cache lock |  0.000021 |
| Sending data                 |  2.943810 |
| Waiting for query cache lock |  0.000061 |
| Sending data                 |  3.330211 |
| Waiting for query cache lock |  0.000025 |
| Sending data                 |  3.411236 |
| Waiting for query cache lock |  0.000023 |
| Sending data                 | 23.339035 |
| end                          |  0.000807 |
| query end                    |  0.000023 |
| closing tables               |  0.000325 |
| freeing items                |  0.001217 |
| logging slow query           |  0.000007 |
| logging slow query           |  0.000011 |
| cleaning up                  |  0.000104 |
+------------------------------+-----------+
100 rows in set (0.00 sec)

Struktury tabel:

CREATE TABLE `attribute` (
  `attribute_id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `attribute_type_id` int(11) unsigned DEFAULT NULL,
  `attribute_value` int(6) DEFAULT NULL,
  `person_id` int(11) unsigned DEFAULT NULL,
  PRIMARY KEY (`attribute_id`),
  KEY `attribute_type_id` (`attribute_type_id`),
  KEY `attribute_value` (`attribute_value`),
  KEY `person_id` (`person_id`)
) ENGINE=MyISAM AUTO_INCREMENT=40000001 DEFAULT CHARSET=utf8;

CREATE TABLE `person` (
  `person_id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `person_name` text CHARACTER SET latin1,
  PRIMARY KEY (`person_id`)
) ENGINE=MyISAM AUTO_INCREMENT=20000001 DEFAULT CHARSET=utf8;

Zapytanie zostało wykonane na serwerze wirtualnym DigitalOcean z dyskiem SSD i 1 GB pamięci RAM.

Zakładam, że może występować problem z projektowaniem bazy danych. Czy masz jakieś sugestie, aby lepiej zaprojektować tę sytuację? A może po prostu dostosować powyższy wybór?

— Jaskółka oknówka
źródło

4

To cena, którą płacisz za projekt EAV. Możesz wypróbować indeks złożony naattribute (person_id, attribute_type_id, attribute_value)

— mustaccio,

1

Spróbowałbym dodać te indeksy: (attribute_type_id, attribute_value, person_id)i (attribute_type_id, person_id, attribute_value)

— ypercubeᵀᴹ

5

I użyj InnoDB, wyrzuć MyISAM. To jest 2015, MyiSAM już dawno nie żyje.

— ypercubeᵀᴹ

2

Po pierwsze - pozbądź się LEWEJ złączki, nie ma to żadnego efektu, ponieważ używasz wszystkich tabel w swoim stanie GDZIE, skutecznie zamieniając wszystkie złączenia na złączenia WEWNĘTRZNE (optymalizator powinien być w stanie to zrozumieć i zoptymalizować, ale lepiej, aby nie utrudniać ). Druga sprawa - wyłącz pamięć podręczną zapytań, chyba że masz silny powód, aby z niej korzystać (= przetestowałeś ją i

— oceniłeś,

2

OT: czy nie jest dziwne, że używasz LIMIT z NASZYM ZAMÓWIENIEM? Czy to zwróci jakieś losowe 100000 wierszy?

— ibre5041,

8

Wybierz kilka atrybutów, które chcesz uwzględnić person. Indeksuj je w kilku kombinacjach - używaj indeksów złożonych, a nie indeksów jednokolumnowych.

To jest w zasadzie jedyne wyjście z EAV-sucks-at-performance, czyli tam, gdzie jesteś.

Oto więcej dyskusji: http://mysql.rjweb.org/doc.php/eav, w tym sugestia użycia JSON zamiast tabeli klucz-wartość.

— Rick James
źródło

3

Dodaj indeksy do attribute:

(person_id, attribute_type_id, attribute_value) i
(attribute_type_id, attribute_value, person_id)

Wyjaśnienie

Przy obecnym projekcie EXPLAINoczekuje, że zapytanie obejrzy 1,265,229 * 4 * 4 * 4 = 80,974,656wiersze attribute. Można zmniejszyć tę liczbę, dodając Composite Index na attributeza (person_id, attribute_type_id). Korzystanie z tego indeksu zapytanie zbada tylko 1 zamiast 4 wiersze dla każdego location, eyecolori gender.

Można przedłużyć ten indeks obejmuje attribute_type_valuerównież: (person_id, attribute_type_id, attribute_value). Spowodowałoby to przekształcenie tego indeksu w indeks pokrywający dla tego zapytania, co również powinno poprawić wydajność.

Ponadto dodanie indeksu do (attribute_type_id, attribute_value, person_id)(ponownie indeksu obejmującego przez włączenie person_id) powinno poprawić wydajność w porównaniu z samym użyciem indeksu, w attribute_valuektórym należy zbadać więcej wierszy. W takim przypadku nastąpi przyspieszenie pierwszego kroku twojego wyjaśnienia: wybranie zakresu od bornyear.

Korzystanie z tych dwóch indeków skróciło czas wykonywania zapytania w moim systemie z ~ 2,0 s do ~ 0,2 s, a wynik wyjaśniania wygląda następująco:

+----+-------------+----------+--------+-------------------------------------+-------------------+---------+--------------------------------+---------+----------+--------------------------+
| id | select_type | table    | type   | possible_keys                       | key               | key_len | ref                            |    rows | filtered | Extra                    |
+----+-------------+----------+--------+-------------------------------------+-------------------+---------+--------------------------------+---------+----------+--------------------------+
|  1 | SIMPLE      | bornyear | range  | person_type_value,type_value_person | type_value_person |       9 |                                | 1861881 |   100.00 | Using where; Using index |
|  1 | SIMPLE      | location | ref    | person_type_value,type_value_person | person_type_value |       8 | bornyear.person_id,const       |       1 |   100.00 | Using where; Using index |
|  1 | SIMPLE      | eyecolor | ref    | person_type_value,type_value_person | person_type_value |       8 | bornyear.person_id,const       |       1 |   100.00 | Using where; Using index |
|  1 | SIMPLE      | gender   | ref    | person_type_value,type_value_person | person_type_value |      13 | bornyear.person_id,const,const |       1 |   100.00 | Using index              |
|  1 | SIMPLE      | person   | eq_ref | PRIMARY                             | PRIMARY           |       4 | bornyear.person_id             |       1 |   100.00 | Using index              |
+----+-------------+----------+--------+-------------------------------------+-------------------+---------+--------------------------------+---------+----------+--------------------------+

— wolfgangwalther
źródło

1

Dzięki za wyczerpującą odpowiedź i wyjaśnienia. Zrobiłem wszystko, o czym wspomniałeś, ale zapytanie nadal zajmuje ~ 2 min. Jaki typ tabeli (innodb, myisam) używasz i jakie dokładne zapytanie zostało wykonane?

— Martin,

1

Oprócz dodawania indeków użyłem dokładnie tych samych danych i definicji, co ty, więc użyłem MyISAM. Zmieniłem pierwszy wiersz twojego zapytania na, SELECT person.person_idponieważ w przeciwnym razie nie zadziałałoby, oczywiście. Czy zrobiłeś to ANALYZE TABLE attributepo dodaniu indków? Możesz również dodać swoje nowe EXPLAINwyniki (po dodaniu indków) do swojego pytania.

— wolfgangwalther

3

Zakładam, że może występować problem z projektowaniem bazy danych.

Używasz tak zwanego projektu Entity-Attribute-Value, który często źle się sprawdza, z założenia.

Czy masz jakieś sugestie, aby lepiej zaprojektować tę sytuację?

Klasycznym relacyjnym sposobem zaprojektowania tego byłoby utworzenie osobnej tabeli dla każdego atrybutu. Ogólnie rzecz biorąc, można mieć te oddzielne tabele: location, gender, bornyear, eyecolor.

Zależy to od tego, czy określone atrybuty są zawsze zdefiniowane dla danej osoby, czy nie. I czy dana osoba może mieć tylko jedną wartość atrybutu. Na przykład osoba zwykle ma tylko jedną płeć. W obecnym projekcie nic nie stoi na przeszkodzie, aby dodać trzy wiersze dla tej samej osoby z różnymi wartościami dla płci. Możesz także ustawić wartość płci nie na 1 lub 2, ale na pewną liczbę, która nie ma sensu, na przykład 987 i nie ma żadnych ograniczeń w bazie danych, które by to uniemożliwiły. Ale to kolejna osobna kwestia utrzymania integralności danych przy projektowaniu EAV.

Jeśli zawsze znasz płeć danej osoby, nie ma sensu umieszczać jej w osobnej tabeli, a lepiej jest mieć GenderIDw persontabeli niepustą kolumnę , która byłaby kluczem obcym do tabeli odnośników z listą wszystkie możliwe płcie i ich imiona. Jeśli znasz płeć danej osoby przez większość czasu, ale nie zawsze, możesz ustawić tę kolumnę na wartość zerową i ustawić ją, NULLgdy informacje nie będą dostępne. Jeśli przez większość czasu płeć danej osoby nie jest znana, lepiej mieć oddzielną tabelę, genderktóra prowadzi do person1: 1 i zawiera wiersze tylko dla osób o znanej płci.

Podobne uwagi dotyczą eyecolori bornyear- jest mało prawdopodobne, aby dana osoba miała dwie wartości dla eyecolorlub bornyear.

Jeśli dana osoba może mieć kilka wartości atrybutu, zdecydowanie umieściłbyś go w osobnej tabeli. Na przykład często zdarza się, że osoba ma kilka adresów (dom, praca, poczta, wakacje itp.), Więc umieściłbyś je wszystkie w tabeli location. Tabele personi locationzostaną połączone 1: M.

A może po prostu dostosować powyższy wybór?

Jeśli używasz projektu EAV, to przynajmniej wykonałbym następujące czynności.

Zestaw kolumn attribute_type_id, attribute_value, person_idaby NOT NULL.
Ustaw klucz obcy, że linki attribute.person_idz person.person_id.
Utwórz jeden indeks w trzech kolumnach (attribute_type_id, attribute_value, person_id). Ważna jest tutaj kolejność kolumn.
O ile mi wiadomo, MyISAM nie honoruje kluczy obcych, więc nie używaj go, zamiast tego użyj InnoDB.

Napiszę takie zapytanie. Użyj INNERzamiast LEFTłączyć i jawnie zapisuj podzapytanie dla każdego atrybutu, aby dać optymalizatorowi wszystkie szanse na użycie indeksu.

SELECT person.person_id
FROM
    person
    INNER JOIN
    (
        SELECT attribute.person_id
        FROM attribute
        WHERE attribute_type_id = 1
            AND location.attribute_value BETWEEN 3000 AND 7000
    ) AS location ON location.person_id = person.person_id
    INNER JOIN
    (
        SELECT attribute.person_id
        FROM attribute
        WHERE attribute_type_id = 2
            AND location.attribute_value = 1
    ) AS gender ON gender.person_id = person.person_id
    INNER JOIN
    (
        SELECT attribute.person_id
        FROM attribute
        WHERE attribute_type_id = 3
            AND location.attribute_value BETWEEN 1980 AND 2000
    ) AS bornyear ON bornyear.person_id = person.person_id
    INNER JOIN
    (
        SELECT attribute.person_id
        FROM attribute
        WHERE attribute_type_id = 4
            AND location.attribute_value IN (2, 3)
    ) AS eyecolor ON eyecolor.person_id = person.person_id
LIMIT 100000;

Ponadto, może być warte podzielenia się attributestolik attribute_type_id.

— Vladimir Baranov
źródło

Uwaga dotycząca wydajności: JOIN ( SELECT ... )nie optymalizuje się dobrze. JOINingbezpośrednio do stołu działa lepiej (ale nadal jest problematyczne).

— Rick James

3

Mam nadzieję, że znalazłem wystarczające rozwiązanie. Inspiruje go ten artykuł .

Krótka odpowiedź:

Utworzyłem 1 tabelę ze wszystkimi atrybutami. Jedna kolumna dla jednego atrybutu. Plus kolumna klucza podstawowego.
Wartości atrybutów są przechowywane w komórkach tekstowych (do wyszukiwania pełnotekstowego) w formacie CSV.
Utworzono indeksy pełnotekstowe. Wcześniej ważne jest, aby ustawić ft_min_word_len=1(dla MyISAM) w [mysqld]sekcji i innodb_ft_min_token_size=1(dla InnoDb) w my.cnfpliku, zrestartuj usługę mysql.
Szukając przykład: SELECT * FROM person_index WHERE MATCH(attribute_1) AGAINST("123 456 789" IN BOOLEAN MODE) LIMIT 1000gdzie 123, są identyfikatory, które są związane osoby powinny w . To zapytanie zajęło mniej niż 1 sekundę.456789attribute_1

Szczegółowa odpowiedź:

Krok 1. Tworzenie tabeli z indeksami pełnotekstowymi. InnoDb obsługuje indeksy pełnotekstowe z MySQL 5.7, więc jeśli używasz wersji 5.5 lub 5.6, powinieneś użyć MyISAM. Czasami wyszukiwanie FT jest jeszcze szybsze niż InnoDb.

CREATE TABLE `person_attribute_ft` (
  `person_id` int(11) NOT NULL,
  `attr_1` text,
  `attr_2` text,
  `attr_3` text,
  `attr_4` text,
  PRIMARY KEY (`person_id`),
  FULLTEXT KEY `attr_1` (`attr_1`),
  FULLTEXT KEY `attr_2` (`attr_2`),
  FULLTEXT KEY `attr_3` (`attr_3`),
  FULLTEXT KEY `attr_4` (`attr_4`),
  FULLTEXT KEY `attr_12` (`attr_1`,`attr_2`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

Krok 2. Wstaw dane z tabeli EAV (encja-atrybut-wartość). Na przykład podany w pytaniu można to zrobić za pomocą 1 prostego SQL:

INSERT IGNORE INTO `person_attribute_ft`
SELECT
    p.person_id,
    (SELECT GROUP_CONCAT(a.attribute_value SEPARATOR ' ') FROM attribute a WHERE a.attribute_type_id = 1 AND a.person_id = p.person_id LIMIT 10) attr_1,
    (SELECT GROUP_CONCAT(a.attribute_value SEPARATOR ' ') FROM attribute a WHERE a.attribute_type_id = 2 AND a.person_id = p.person_id LIMIT 10) attr_2,
    (SELECT GROUP_CONCAT(a.attribute_value SEPARATOR ' ') FROM attribute a WHERE a.attribute_type_id = 3 AND a.person_id = p.person_id LIMIT 10) attr_3,
    (SELECT GROUP_CONCAT(a.attribute_value SEPARATOR ' ') FROM attribute a WHERE a.attribute_type_id = 4 AND a.person_id = p.person_id LIMIT 10) attr_4
FROM person p

Wynik powinien być mniej więcej taki:

mysql> select * from person_attribute_ft limit 10;
+-----------+--------+--------+--------+--------+
| person_id | attr_1 | attr_2 | attr_3 | attr_4 |
+-----------+--------+--------+--------+--------+
|         1 | 541    | 2      | 1927   | 3      |
|         2 | 2862   | 2      | 1939   | 4      |
|         3 | 6573   | 2      | 1904   | 2      |
|         4 | 2432   | 1      | 2005   | 2      |
|         5 | 2208   | 1      | 1995   | 4      |
|         6 | 8388   | 2      | 1973   | 1      |
|         7 | 107    | 2      | 1909   | 4      |
|         8 | 5161   | 1      | 2005   | 1      |
|         9 | 8022   | 2      | 1953   | 4      |
|        10 | 4801   | 2      | 1900   | 3      |
+-----------+--------+--------+--------+--------+
10 rows in set (0.00 sec)

Krok 3. Wybierz z tabeli z zapytaniem takim jak to:

mysql> SELECT SQL_NO_CACHE *
    -> FROM `person_attribute_ft`
    -> WHERE 1 AND MATCH(attr_1) AGAINST ("3000 3001 3002 3003 3004 3005 3006 3007" IN BOOLEAN MODE)
    -> AND MATCH(attr_2) AGAINST ("1" IN BOOLEAN MODE)
    -> AND MATCH(attr_3) AGAINST ("1980 1981 1982 1983 1984" IN BOOLEAN MODE)
    -> AND MATCH(attr_4) AGAINST ("2,3" IN BOOLEAN MODE)
    -> LIMIT 10000;
+-----------+--------+--------+--------+--------+
| person_id | attr_1 | attr_2 | attr_3 | attr_4 |
+-----------+--------+--------+--------+--------+
|     12131 | 3002   | 1      | 1982   | 2      |
|     51315 | 3007   | 1      | 1984   | 2      |
|    147283 | 3001   | 1      | 1984   | 2      |
|    350086 | 3005   | 1      | 1982   | 3      |
|    423907 | 3004   | 1      | 1982   | 3      |
... many rows ...
|   9423907 | 3004   | 1      | 1982   | 3      |
|   9461892 | 3007   | 1      | 1982   | 2      |
|   9516361 | 3006   | 1      | 1980   | 2      |
|   9813933 | 3005   | 1      | 1982   | 2      |
|   9986892 | 3003   | 1      | 1981   | 2      |
+-----------+--------+--------+--------+--------+
90 rows in set (0.17 sec)

Zapytanie wybiera wszystkie wiersze:

dopasowanie co najmniej jednego z tych identyfikatorów w attr_1:3000, 3001, 3002, 3003, 3004, 3005, 3006 or 3007
I jednocześnie pasujące 1do attr_2(ta kolumna reprezentuje płeć, więc jeśli to rozwiązanie zostało dostosowane, powinno być smallint(1)z prostym indeksem itp.)
I w tym samym czasie dopasowywania przynajmniej jednego 1980, 1981, 1982, 1983 or 1984zattr_3
I jednocześnie dopasowując 2lub 3wattr_4

Wniosek:

Wiem, że to rozwiązanie nie jest idealne i idealne w wielu sytuacjach, ale może być stosowane jako dobra alternatywa dla projektu stołu EAV.

Mam nadzieję, że to komuś pomoże.

— Jaskółka oknówka
źródło

1

Uważam za bardzo mało prawdopodobne, aby ten projekt działał lepiej niż twój oryginalny projekt z indeksami złożonymi. Jakie testy wykonałeś, aby je porównać?

— ypercubeᵀᴹ

0

Spróbuj użyć wskazówek indeksu zapytań, które wyglądają odpowiednio

Wskazówki dotyczące indeksu MySQL

— Muhammad Muazzam
źródło

1

Wskazówki mogą pomóc w jednej wersji zapytania, ale mogą zaszkodzić innej. Pamiętaj, że Optymalizator wybrał bornyear jako najlepszą pierwszą tabelę, prawdopodobnie dlatego, że odfiltrował najbardziej niepożądane wiersze.

— Rick James,