MySQL: Zoptymalizuj UNION z „ORDER BY” w zapytaniach wewnętrznych

Właśnie skonfigurowałem system rejestrowania, który składa się z wielu tabel o tym samym układzie.

Dla każdego źródła danych istnieje jedna tabela.

W przypadku przeglądarki dziennika chcę

• UNION wszystkie tabele dziennika ,
• filtruj je według konta ,
• dodaj pseudokolumnę do identyfikacji źródła,
• posortuj je według czasu ,
• i ogranicz je do stronicowania .

Wszystkie tabele zawierają pole o nazwie zeitpunktindeksowana kolumna daty / godziny.

Moja pierwsza próba to:

(SELECT l.id, l.account_id, l.vnum, l.count, l.preis, l.zeitpunkt AS zeit,
 'hp' AS source FROM is_log AS l WHERE l.account_id = 730)

UNION

(SELECT l.id, l.account_id, l.vnum, l.count, l.preis, l.zeitpunkt,
 'ig' AS source FROM ig_is_log AS l WHERE l.account_id = 730)

ORDER BY zeit DESC LIMIT 10;

Optymalizator nie może tutaj użyć indeksów, ponieważ wszystkie wiersze z obu tabel są zwracane przez podzapytania i sortowane po UNION.

Moje obejście było następujące:

(SELECT l.id, l.account_id, l.vnum, l.count, l.preis, l.zeitpunkt AS zeit,
 'hp' AS source FROM is_log AS l WHERE l.account_id = 730
 ORDER BY l.zeitpunkt DESC LIMIT 10)

UNION

(SELECT l.id, l.account_id, l.vnum, l.count, l.preis, l.zeitpunkt,
 'ig' AS source FROM ig_is_log AS l WHERE l.account_id = 730
 ORDER BY l.zeitpunkt DESC LIMIT 10)

ORDER BY zeit DESC LIMIT 10;

Spodziewałem się, że silnik zapytań użyje tutaj indeksów, ponieważ oba podkwerendy powinny zostać posortowane i ograniczone już przed UNION, który następnie łączy i sortuje wiersze.

Naprawdę myślałem, że to będzie to, ale uruchomienie EXPLAINzapytania powoduje, że podkwerendy wciąż przeszukują obie tabele.

EXPLAINingsame podkwerendy pokazują mi pożądaną optymalizację, ale UNIONingrazem ich nie robi.

Przegapiłem coś?

Wiem, że ORDER BYklauzule w UNIONpodzapytaniach są ignorowane bez znaku LIMIT, ale jest pewien limit.

Edycja:
W rzeczywistości prawdopodobnie będą też zapytania bezaccount_idwarunku.

Tabele już istnieją i są wypełnione danymi. Mogą występować zmiany w układzie w zależności od źródła, dlatego chcę je podzielić. Ponadto klienci rejestrujący używają różnych poświadczeń z określonego powodu.

Muszę zachować rodzaj warstwy między czytnikami dzienników a rzeczywistymi tabelami.

Oto plany wykonania dla całego zapytania i pierwszego podzapytania, a także szczegółowo układ tabeli:

https://gist.github.com/ca8fc1093cd95b1c6fc0

Z ciekawości możesz wypróbować tę wersję? Optymalizator może oszukać te same indeksy, których użyłyby podzapytania osobno:

SELECT *
FROM
(SELECT l.id, l.account_id, l.vnum, l.count, l.preis, l.zeitpunkt AS zeit,
 'hp' AS source FROM is_log AS l WHERE l.account_id = 730
 ORDER BY l.zeitpunkt DESC LIMIT 10) 
    AS a

UNION ALL

SELECT *
FROM
(SELECT l.id, l.account_id, l.vnum, l.count, l.preis, l.zeitpunkt,
 'ig' AS source FROM ig_is_log AS l WHERE l.account_id = 730
 ORDER BY l.zeitpunkt DESC LIMIT 10)
    AS b

ORDER BY zeit DESC LIMIT 10;

Nadal uważam, że najlepszym indeksem, jaki możesz mieć, jest związek (account_id, zeitpunkt). Dałoby to szybko 10 rzędów i żadne sztuczki nie byłyby potrzebne.