Musze koniecznie uzyc LEFT JOIN, dlatego, ze musze wyswietlac rowniez wartosci NULL i je pogrupowac.

Mam dwie tabele, jedna skaladajaca sie (do tej pory) z okolo 50000 rekordow, struktura:

[SQL] pobierz, plaintext 
CREATE TABLE `email_confirm` (
  `id` int(3) NOT NULL AUTO_INCREMENT,
  `no` varchar(100) NOT NULL,
  `email` varchar(100) NOT NULL',
  `date` datetime NOT NULL,
  `ver` varchar(6) NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `no` (`no`),
  KEY `email` (`email`)
) ENGINE=MyISAM;
[SQL] pobierz, plaintext 

A tu druga tabela, zawierajaca kilkanascie rekordow, w ktorej wpisuje ile maili zostalo wyslanych:

[SQL] pobierz, plaintext 
CREATE TABLE `email_confirm_sent` (
  `id` int(3) NOT NULL AUTO_INCREMENT,
  `no` varchar(100) NOT NULL,
  `quantity` int(10) NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `no` (`no`),
  KEY `quantity` (`quantity`)
) ENGINE=MyISAM;
[SQL] pobierz, plaintext 

I teraz zapytanie, ktore grupuje wszystkie wyslane maile, laczy sie z druga tabela i na tej podstawie moge wylicz procent otwarte/wyslane:

[SQL] pobierz, plaintext 
SELECT email_confirm.no, COUNT(email_confirm.no) AS counts, quantity
FROM email_confirm LEFT JOIN email_confirm_sent
ON email_confirm.no = email_confirm_sent.no
WHERE email NOT LIKE '%spa.pl'
GROUP BY email_confirm.no HAVING counts > 10
[SQL] pobierz, plaintext 

I problem w tym, ze ten kochany LEFT JOIN opoznia generacje wynikow do okolo 40sek.

Mozna to jakos zoptymalizowac?

Skoro ta druga tabela ma zaledwie kilkanaście rekordów,
to może najpierw wczytaj sobie do tablicy całą drugą
tabelę a w zapytaniu zrezygnuj z LEFT JOIN.

Jeśli nadal zapytanie będzie szło wolno
to znaczy, ze problem nie leżał w LEFT JOIN
(pierwszym podejżanym będzie LIKE)

Skomentuje najpierw druga odpowiedz: nie, LIKE nie jest problemem, gdyz testowalem z ta dyrektywa i bez niej. Czas ten sam.

Natomiast co do pierwszej odpowiedzi, nie moge wrzucic drugiej tabeli do pierwszej, gdyz:

1. Pierwsza tabela jest bardzo czesto aktualizowana (dodawane co kilka minut nowe rekordy)
2. Zapytanie jest czesto uruchamiane przez kilka osob w firmie


Dodam jeszcze, ze na pewno jest to LEFT JOIN, bo jezeli zrobie INNER JOIN, wynik generowany jest w mig, ale gubie wartosci NULL (a te potrzebuje)

Ależ to nie ma znaczenia,
mam na myśli tablicę w sensie php
Może źle się wyraziłem w poprzednim poście i myśleś o tabeli SQL ?
Przecież za każdym razem jak będziesz wykonywał zapytanie,
to wczytujesz drugą tabelę do tablicy php,

To co proponuje w sensie merytorycznym
zwraca dane takie same jak twój LEFT JOIN,
chyba nie sądzisz, że w ciągu wykonywania zapytania
trwającego mniej niż sekundę zajdą jakieś poważne zmiany?
Jak tak co jest mało prawdopodobne to użytkownik dostanie wynik
sprzed kilku sekundy co można uznać za aktualny

Mam indeksy, co widac w pierwszym poscie przy definicji tabel.

A co za roznica czy zrobie RIGHT JOIN czy LEFT JOIN, jezeli ich algorytm jest taki sam, tylko roznia sie tym, ze argument zamiast z lewej, jest z prawej strony.

Z dokumentacji MySQL 5:
The implementation of RIGHT JOIN is analogous to that of LEFT JOIN with the roles of the tables reversed.

Poza tym "count" liczy te z NULL tez, dlatego, ze je grupuje.

Napisalem tez, ze musze koniecznie uzyc LEFT JOIN, a to dlatego, ze zalezy mi na zliczaniu tych rekordow ktore sa NULL.

Wyjasnie to na przykladzie: Wysylam iles tam tysiecy maili dziennie. Kazda grupa maili na swoj tytul i po otwarciu kazdego z nich zapisywany jest w bazie z danym tytulem i adresem email osoby otwierajacej. To jest pole 'no'.
Druga tabela, natomiast, jest zwykla sumaryczna tabela tematow, z kolumna ile maili zostalo wyslanych z danej grupy.

I dlatego wlasnie musze miec NULL, bo jezeli po zlaczeniu nie ma wartosci w drugiej tabeli, znaczy to, ze musi tam byc wpisana ilosc wyslanych maili.

A tu INNER JOIN odpada.