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

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?

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ść.

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              |
+----+-------------+----------+--------+-------------------------------------+-------------------+---------+--------------------------------+---------+----------+--------------------------+

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.

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

Krótka odpowiedź:

1. Utworzyłem 1 tabelę ze wszystkimi atrybutami. Jedna kolumna dla jednego atrybutu. Plus kolumna klucza podstawowego.
2. Wartości atrybutów są przechowywane w komórkach tekstowych (do wyszukiwania pełnotekstowego) w formacie CSV.
3. 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.
4. 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.

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

Wskazówki dotyczące indeksu MySQL