[sokytsinolop]

#mysql #programowanie

Cześć mam takie zapytanie
SELECT games.gid,games.value,games.itemcount, games.hash,games.salt,games.winnerp, users.username,users.avatar, (SELECT SUM(price) FROM items WHERE items.gid = games.gid AND items.uid = games.wid) as dd FROM games INNER JOIN users ON games.wid=users.uid ORDER BY gid DESC LIMIT 15
pokolorowane: https://gist.github.com/cymruu/37396148a5d38c9107a69a40fbd072da
I działa dobrze, ale niestety wykonuje się 1,5 sekundy a wydaje mi się, że to dużo za dużo. W jaki sposób mogę to zoptymalizować?

[wytrzzeszcz]

@sokytsinolop: no Join ma złożoność czasową n^2 więc nie jest kolorowo

[GotoFinal]

@wytrzzeszcz: jako że na bazach się niezbyt znam bynajmniej na ich wydajności, to ten join ma n^2, czy każdy join ma n^2? I nie znasz może jakiegoś fajnego artykułu o tym? czego unikać? co robić? (ale książki mnie nie interesują, chce tylko coś małego dla zaspokojenia ciekawości)

[wytrzzeszcz]

@GotoFinal: @sokytsinolop: Join to podrelacja
a każda relacja to podzbiór iloczynu kartezjanskiego
co znaczy że próbuje każdy z każdym i filturje
znaczy głupiu DBMS alle nie wiem czy są mądre

[GotoFinal]

@wytrzzeszcz: a hashować się nie da (znaczy się, czy silnik bazy nie może hashować)? mam dane i to po czym łączysz, z obu tabel, co nie pasuje to wrzucam do hashmapy i wtedy kolejny element może znaleźć pasujący element w hashmape bo klucz jest taki sam bo w końcu po nim łączysz? A wyszukiwanie w hashmapie już powinno być szybsze, więc już zależnie od szczęśnie od N do N^2, gdzie

[wytrzzeszcz]

@GotoFinal: no robi sie indexy i inne takie bajery
ale ogólnie n^2 by tak nie bolało jak byś nie musiał co chwila z---------c do HDD

[GotoFinal]

@wytrzzeszcz: no to bazy chyba też potrafią przenieść to co trzeba do pamięci i to co jest często używane a się mieści?

[wytrzzeszcz]

@GotoFinal ja o pesymistyczne.a ty optymistycznie ;)

[GotoFinal]

@wytrzzeszcz: no mnie po prostu bardziej interesuje praktyka niż teoria :D

[wytrzzeszcz]

@GotoFinal to w praktyce jest gorzej niż w teorii

[MQs]

@sokytsinolop: Chyba się optymalizacja gubi na tym, że nie wie dla jakich gid ma liczyć sumy i buduje całą tabelę przed sortowaniem i wyświetleniem ostatnich 15. Tego selecta na sumy dołączyłbym przez JOIN (spróbuj też podzapytaniem ograniczyć wyniki wcześniej dając wynik jako główną tabelę z ORDER BY + LIMIT).

[Darjo]

@sokytsinolop: a ile masz rekordow w tych tabelach? jesli tysiace a nie miliony to nie powinno 1,5 sek sie wykonywac. masz indeksy/klucze pozakladane poprawnie?

[sokytsinolop]

@Darjo: games poniżej 500, items poniżej 2k więc wynik jest bardzo zły :)

[sokytsinolop]

@Darjo: @MQs: @wytrzzeszcz: @GotoFinal: sprawdziłem i bez ORDER BY games.gid` zaptytanie wykonuje się w 0.2s, wiecie może dlaczego?

[MQs]

@sokytsinolop: Zrobi 15 dowolnych wierszy i już wiadomo, że więcej nie trzeba. Żeby wyłowić 15 konkretnych musi mieć najpierw wszystkie. Zwłaszcza, że JOIN będzie filtrował te niepasujące.

[sokytsinolop]

@MQs:
SELECT games.gid,games.value,games.itemcount, games.hash,games.salt,games.winnerp, users.username,users.avatar, (SELECT SUM(price) FROM items WHERE items.gid = games.gid AND items.uid = games.wid) as dd FROM games INNER JOIN users ON games.wid=users.uid
bez limit i bez order by - 0.16s
limit 200,500 - 0.1s
order by games gid - 1.7096s
order by games gid, limit 15

[MQs]

@sokytsinolop: Jeśli sortowanie spowalnia bez względu na ilość wierszy to problemu bym szukał w indeksach. Zobacz co wyrzuca EXPLAIN EXTENDED SELECT...

[plushy]

no Join ma złożoność czasową n^2 więc nie jest kolorowo

@wytrzzeszcz: Nie można tak na to patrzeć. Istnieją różne algorytmy dla joinów, istnieją indeksy, planner decyduje o tym kiedy zostanie join użyty.

[plushy]

@sokytsinolop: spróbuj indeksy na games(gid DESC,wid) i users(uid).

[sokytsinolop]

SELECT games.gid,games.value,games.itemcount, games.hash,games.salt,games.winnerp, users.username,users.avatar, (SELECT SUM(price) FROM items WHERE items.gid = games.gid AND items.uid = games.wid) as dd FROM games INNER JOIN users ON games.wid=users.uid ORDER BY gid DESC LIMIT 15

@plushy: nadal 1.8s :/

[plushy]

@sokytsinolop: Explain, schemat tabel, liczba rekordów?