(za)długi czas wykonania zapytania Opcje

[devnul]

Jak w temacie. Mam zapytanie:

[SQL] pobierz, plaintext 
SELECT `n`.`news_id`, `t`.`newstext_title`, `t`.`newstext_text`, `n`.`news_publish`,`p`.* 
FROM `news` AS `n` 
JOIN `newstext` AS `t` ON `n`.`news_id`=`t`.`newstext_parent` 
JOIN `news2cat` AS `nc` ON `n`.`news_id`=`nc`.`news2cat_news` 
LEFT JOIN `news2photo` AS `np` ON `np`.`news2photo_news`=`n`.`news_id` 
LEFT JOIN `photo` AS `p` ON `np`.`news2photo_photo`=`p`.`photo_id` 
WHERE `n`.`news_status`='1' AND `n`.`news_publish`<='1198155351' AND (`n`.`news_publishend`>='1198155351' OR `n`.`news_publishend`=0) AND `nc`.`news2cat_category`
IN ('1', '2', '3', '4', '11', '5', '13', '8', '6', '14', '20', '7', '15', '9', '10', '16', '17', '18', '19', '12') 
GROUP BY `n`.`news_id` 
ORDER BY `n`.`news_publish` DESC LIMIT 0, 10
[SQL] pobierz, plaintext 

i wykonuje się ono w granicach 20 sekund co jest nie do przyjęcia. W tabelach news i newstext znajduje się po około 80 tysięcy rekordów w tabeli photo jest około 40 tysięcy wpisów tabela news2photo to około 50 tysięcy rekordów.
Pytanie co zrobić żeby przyspieszyć to zapytanie do jakiegoś znośnego czasu?

Ten post edytował devnul 3.05.2008, 15:54:19

[kitol]

Założyć indeksy (jeżeli ich nie ma) na kolumny po których łaczysz oraz na kolumny które występują w klauzuli WHERE

[devnul]

są indeksy na wszystkich kolumnach po których łącze i wszystkich które są w WHERE (i paru innych - bo do innych zapytań potrzebowałem)

Ten post edytował devnul 20.12.2007, 14:29:19

[Jarod]

Daj przed zapytaniem explain i zobacz co da się jeszcze zrobić.. Tu masz w skrócie napisane co każdy opis oznacza http://0day.pl/index.php/archives/12

[kitol]

Najlepiej wklej tu tego explaina

[devnul]

EXPLAIN - dużo to raczej nie daje

[php programmer]

Wywal wszystkie JOINY,

zamiast tego zrób na początku jedno zapytanie odpowiadające głownemu zapytaniu ale
pobierające tylko id z głównej tabeli
id zbierasz w jakiejś tabeli php-owej

potem robisz osobna zapytanie dla zapytania głównego
oraz osobne zapytanie odpowiadające kazdemu JOIN
gdzie warunkiem jest id nalezace to tych zebranych w tapeli php-owej

Wyniki kazdego JOINA zapisujesz w tablicy php-owej (oczywiście innej niż ta wyżej,
osobna taliba dla kazdego JOIN), ale w taki sposób,
że indeksami są id table głównej, dzięki czemu można się potem bezpośrednio
odwoływać do danych JOIN-owych

niedawno zastowowałem tego typu rozwiązanie i bardzo pomogło
w beznadziejnej wydawałoby się sytuacji, bo danych było tyle, że
nawet jednego JOINa nie można było dodać

Ten post edytował php programmer 21.12.2007, 08:42:41

[devnul]

rozwiązanie nie za bardzo bo za dużo tu zależności np rekord znajdujący się w tabeli news nie musi mieć pokrycia w tabeli newstext (skąd mam wiedzieć ile wyciągnąć id z news żeby trafić na 100% na 10 istniejących w tabeli newstext, bo przecierz może być teorytycznie np 1000 rekordów po koleii w news nie mających odpowiednika w newstext).

Jakieś inne pomysły?

[php programmer]

Wyciągasz wszystkie id z news, które spełniają warunek głównego zapytania,
brak pokrycia niczemu nie szkodzi, jeśli nie chcesz wyświetlać news bez pokrcia,
sprawdzasz w pętli (czyli złożoność obliczeniowa liniowa)

[PHP] pobierz, plaintext 
<?php
$count = count($TablicaNews);
 
for ($i=0;$i<$count;$i++)
	if (!isset($TablicaNewsText[$i])) unset($TablicaNews[$i]);
?>
[PHP] pobierz, plaintext 

i tu na przykład widać dlaczego indeksami tablic podrzędnych
są id z głownej elementów tabeli (bezpośrednio się odwołujemy)

PS. Swoją drogą nie warto tworzyć aż tylu powiązanych tabel,
np. wstawianie tekstu newsa do innej tabeli zamiast dać w tej samej

Ten post edytował php programmer 21.12.2007, 08:46:02

[devnul]

@php programmer: Ty chyba nie doczytałeś tego co napisałem w pierwszym poście w obu tabelach ma po około 80 tysięcy rekordów - niekoniecznie pokrywających się co oznacza wyciągnięcie 2*po 80 tysięcy id z obu tabel i sprawdzenie ich w pętli - na dość mocno obciążonym serwerze takie działanie nie przejdzie z przyzwoitą szybkością.

Rozbicie newsa na 2 tabele było mi potrzebne z pewnych względów o których pisać tutaj nie będę bo nie w tym problem, gdyby tak nie było - wierz mi że te tabele byłyby jedną.

Ten post edytował devnul 21.12.2007, 13:21:13

[kitol]

80 tyś rekordów to nie jest dużo. Przy dobrze ustawionych indeksach powinno śmigać. Bez definicji tabel ciężko coś więcej powiedzieć (explain nie otwiera się). Czy w tabelach masz pole TEXT lub BLOB? Jeżeli tak to wydaje mi się że lepiej jest zrobić oddzielną tablicę zawierającą tylko pole TEXT i jakiś id a resztę informacji trzymać oddzielnie.