DevProTalk - PHP brzi od MySQL-a u izvlacenju lookup vrednosti?!?!?

DevProTalk (http://www.devprotalk.com/index.php)

- PHP (http://www.devprotalk.com/forumdisplay.php?f=9)

- - PHP brzi od MySQL-a u izvlacenju lookup vrednosti?!?!? (http://www.devprotalk.com/showthread.php?t=798)

Citat:

Originalno napisao Pedja

Cini mi se da je ovde kvaka u asocijativnom nizu PHP-a posto to izgleda radi vraski brzo, bez obzira na poredjenje sa MySQL-om. Ne znam kako to radi interno, ali mi se nikako ne uklapa da je brze nego sto to radi MySQL.

pa asocijativni niz je svakako brzi jer on:
1. ima uvek sve podatke u memoriji (indexi se keshiraju, ali su ipak na disku)
2. radi kao hash tabela, a mysql indexi su valjda B-stabla. Hash na osnovu kljuca racuna formulom direktno poziciju podatka i pristupa mu direktno(ili u par koraka kod kolizija), dok stablo zahteva spustanje po cvorovima...

medjutim priznajem da nisam imao pojma da je tolika razlika..

postoji jos jedan problem kod mysql join-ova, kad ima puno podataka u tabela nad kojima se radi join. Ako ih pustis na 2 tabele od kojih jedna ima npr. 20 miliona recorda mozes slobodno da zaboravis na server, mrtav je, sa ili bez indexa. Pravio sam neke spajdere koji skupljaju uzasno mnogo podataka, i morali smo da splitujemo tabele svakih milion, milion i po recorda, jer cela baza postane uzasno spora...

Apropo indeksa

Kod mene je isti slucaj kao i kod ivanhoe da se index na polju category_id ne koristi, ali obratite paznju sta se desava u sledecim situacijama.

Kôd:

mysql> create index test on master (category_id,master_id);

Query OK, 40000 rows affected (0.31 sec)

Records: 40000  Duplicates: 0  Warnings: 0



mysql> explain SELECT m.*, c.description FROM master m LEFT JOIN categories c ON m.category_id = c.category_id;

+----+-------------+-------+--------+---------------+---------+---------+--------------------+-------+-------------+

| id | select_type | table | type   | possible_keys | key     | key_len | ref                | rows  | Extra       |

+----+-------------+-------+--------+---------------+---------+---------+--------------------+-------+-------------+

|  1 | SIMPLE      | m     | index  | NULL          | test    | 9       | NULL               | 40000 | Using index |

|  1 | SIMPLE      | c     | eq_ref | PRIMARY       | PRIMARY | 4       | news.m.category_id |     1 |             |

+----+-------------+-------+--------+---------------+---------+---------+--------------------+-------+-------------+

2 rows in set (0.01 sec)



mysql> SELECT m.*, c.description FROM master m LEFT JOIN categories c ON m.category_id = c.category_id;



................results bla bla.......

40000 rows in set (0.15 sec)



mysql> create index test on master (master_id,category_id);

Query OK, 40000 rows affected (0.29 sec)

Records: 40000  Duplicates: 0  Warnings: 0



mysql> explain SELECT m.*, c.description FROM master m LEFT JOIN categories c ON m.category_id = c.category_id;

+----+-------------+-------+--------+---------------+---------+---------+--------------------+-------+-------------+

| id | select_type | table | type   | possible_keys | key     | key_len | ref                | rows  | Extra       |

+----+-------------+-------+--------+---------------+---------+---------+--------------------+-------+-------------+

|  1 | SIMPLE      | m     | index  | NULL          | test    | 9       | NULL               | 40000 | Using index |

|  1 | SIMPLE      | c     | eq_ref | PRIMARY       | PRIMARY | 4       | news.m.category_id |     1 |             |

+----+-------------+-------+--------+---------------+---------+---------+--------------------+-------+-------------+

2 rows in set (0.00 sec)



mysql> SELECT m.*, c.description FROM master m LEFT JOIN categories c ON m.category_id = c.category_id;

................results bla bla.......

40000 rows in set (0.44 sec)



mysql> drop index test on master;

Query OK, 40000 rows affected (0.22 sec)

Records: 40000  Duplicates: 0  Warnings: 0



mysql> SELECT m.*, c.description FROM master m LEFT JOIN categories c ON m.category_id = c.category_id;

................results bla bla.......

40000 rows in set (0.37 sec)

Da napomenem da je situacija sa rezultatima identicna bilo da je u pitanju INNER ili LEFT join. Vreme izvrsavanja je bilo identicno i posle vise izvrsavanja istog select-a.

Jasno mi je da do poboljsanja u brzini moze doci zahvaljujuci indeksiranom citanju cele tabele master. Ocigledno je da redosled igra ulogu, ali zasto je zapravo select sporiji kada je master_id na prvom mestu u indeksu (tj kada je category_id na prvom mestu)?

[edit]Ono sto je jos zanimljivije - kako to da explain ne primeti anomaliju koja ocigledno dovodi do usporenja prilikom selecta?[/edit]

Citat:

Originalno napisao ivanhoe

moj mysql (4.1.9-max na windowsima) prikaze drugacije:
...

Odnosno gledace sva polja tabele master, i za inner i za left join, bas kao i kad nema indexa.. sto se pokaze i kad se pusti ovaj Pedjin test, jer se dobije skoro isti rezultati...bar sa myisam tabelama, kasno je pa me mrzi da probam innoDB kako se ponasa...

Kod mene MySQL 4.1.8-nt innodb tabele. Otud razlika u explain-u.

MySQL 4.0.26.

na InnoDB tablicama, rezultati su podjednaki, a JOIN je u prosjeku nesto brzi. jedan od rezultata:
===============================

Summary: Join took 0.28575801849365 . Separate queries took 0.36347579956055

sa MyISAM tablicama, rezultati su podjednaki, iako su separate queries u prosjeku neznatno brzi. jedan od rezultata:
===============================

Summary: Join took 0.65324687957764 . Separate queries took 0.58501100540161

Nesto mi ne valja trenutno sa MySQL serverom pa ne mogu kreirati foreign keys na master tabeli. je li probao netko to i sa kakvim rezultatima?