[kohana] mysql has gone away Opcje

[nmts]

Pracując dzisiaj z KO3 napotkałem błąd jak w tytule, który powodował moduł Auth. Wylogowanie (usunięcie ciastek), i ponowne zalogowanie pomogło. Problem powraca (trudno określić kiedy), mogę w późniejszym czasie przeprowadzić głębszą analizę Auth, ale może ktoś mi jej oszczędzi. (IMG:style_emoticons/default/winksmiley.jpg)

[PHP] pobierz, plaintext 
 ERROR: ErrorException [ 2 ]: mysql_query() [function.mysql-query]: MySQL server has gone away ~ MODPATH/database/classes/kohana/database/mysql.php [ 171 ]
[PHP] pobierz, plaintext 

Coś jednak Auth nie jest głównym winowajcą, bo jakieś powołanie instancji session z Auth robi problem... problem zdarza się w różnych sytuacjach, np. usuwam rekord, a następnia muli, muli i po bardzo długim (to akurat wina długiego timeouta) czasie mysql has gone away.

Przykładowo zarejestrowałem użytkownika, pokazało strone - potwierdzenie, po czym przejście na stronę główną już jest nie możliwe bo coś muli - nie mam pojęcia jak sprawdzić co, analizowanie bebechów Kohany średnio mi się podoba. (IMG:style_emoticons/default/sad.gif)

Przykładowo wynik z Kohany po zarejestrowaniu (z sytuacji powyżej):
http://img510.imageshack.us/img510/3495/profilerr.jpg

Przetestowałem bazę na innym serwerze to admin stwierdził, że mu takie zapytanie bazę blokuje: (wtf w ogóle, skąd niby takie zap. miałoby blokować bazę)

[PHP] pobierz, plaintext 
SELECT (SELECT COUNT(objects.id) FROM objects WHERE cities.id = objects.city_id) AS `objects_count`, `cities`.* FROM `objects`, `cities` GROUP BY `cities`.`id` ORDER BY `objects_count` DESC LIMIT 20 (1)
[PHP] pobierz, plaintext 

Ten post edytował nmts 17.01.2011, 12:39:00

[kalmaceta]

po co te podzapytanie w jest w tym zapytaniu

[thek]

Nie patrzyłem czemu, ale dla mnie zapytanie jest mega niewydajne. Weź tabelę obiektów, złącz ją z cities, pogrupuj i voila. O ile rozumiem CO chcesz tym zapytaniem zrobić (IMG:style_emoticons/default/smile.gif)
Coś jak :

[SQL] pobierz, plaintext 
SELECT c.*, count(o.id) AS liczba FROM objects AS o LEFT JOIN cities AS c ON c.id = o.city_id GROUP BY c.id ORDER BY liczba DESC LIMIT 20
[SQL] pobierz, plaintext 

A bazka się sypie bo masz iloczyn kartezjański tych tabel... Wszystkie kombinacje możliwe między cities i objects (taki jest efekt wymieniania tabel po przecinku) i jeszcze podzapytaniem wewnętrznym poganiane (IMG:style_emoticons/default/winksmiley.jpg) Masz więc ostre pojechanie po bazie i się dziwisz, że zdechła? Niech w każdej ma choćby po 1000 rekordów to summa sumarum wychodzi Ci 1000000 kombinacji a do tego jeszcze podzapytanie nieskorelowane (IMG:style_emoticons/default/winksmiley.jpg) To i blokuje bazka się bo nie zdoła szybko tego przerobić.

Powód edycji: [thek]:

[nmts]

Wygląda na to, że jednak to zapytanie było problemem, choć z początku wydawało mi się to nie możliwe bo nie za każdym razem wywalało bazę. Cóż, sql u mnie jeszcze kuleje. (IMG:style_emoticons/default/smile.gif)

[thek]

Przy takich zapytaniach licho wie ile czasu to zajmuje i kiedy może wywalić bazę. Wymienianie tabel po przecinku jest najgorszym możliwym wydajnościowo typem złączenia (każdy z każdym) i należy go unikać za wszelką cenę jeśli to tylko możliwe. Jeśli do tego dorzucasz podzapytania nieskorelowane to masz bombę z opóźnionym zapłonem. Ale że to jest SELECT to normalnie możesz nie zauważyć kiedy to się dzieje, bo SELECTy nie blokują tabel czy wierszy (zależy od silnika) jak INSERT czy UPDATE. Robić się może więc wiele gdzieś w tle i w trakcie działania aplikacji, ni stąd, ni zowąd, nagle kończą się zasoby lub następuje jakaś operacja blokująca i baza wyciąga kopyta na innej, niewinnej, operacji. Tak jak w przysłowiu: "Kowal zawinił, cygana powiesili" (IMG:style_emoticons/default/winksmiley.jpg)