|
Je vais quand même démontrer que mon affirmation ci-dessus (à savoir "Si les données sont bien indexées, y'a pas de raison que ça dégrade les perfs sur un query bien écrit...") est vraie - je promets au passage que c'est la dernière fois que je parlerai technique sur un des forums de MH.
Les tests ont été effectués sur un serveur Linux avec deux pov' proc en SMP. RAM utilisée : dans les 300M pour la base. 2 disques : un pour le système et un pour tout le reste => on peut pas dire que ça soit un bète de course - serveur un peu chargé par des gens qui bossent :-) pendant les tests
-- On cree un espace pour stocker nos données => rien d'optimisé ici, tous les paramètres
-- sont par défaut. On va utiliser le même espace de stockage pour les données et les index.
SQL> create tablespace TEST datafile '/u03-b/oradata/GFPSBAP0/test_fred.dbf' size 500M ;
Tablespace created.
Elapsed: 00:00:12.64
-- On cree une table qui doit vaguement ressembler à la table des évènements de MH
-- => il manque des champs ici mais le principe est là
-- on met 800 evènements par troll (ça me parait pas mal)
SQL> create table evt1 (the_date date, troll_id number, evt varchar2(40)) tablespace TEST ;
Table created.
Elapsed: 00:00:00.05
SQL> begin
2 for i in 1..8000
3 loop
4 insert into evt1 values (sysdate+i, round(i/800), 'blabla' || i) ;
5 end loop ;
6 end ;
7 /
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.58
SQL> select count(*) from evt1 ;
COUNT(*)
----------
8000
Elapsed: 00:00:00.00
SQL> commit ;
Commit complete.
Elapsed: 00:00:00.02
-- Voila notre table; on cree maintenant un index sur le numero de troll
-- et on l'analyze; selon la doc MYSQL - ou alors j'ai pas tout lu ce qui est
-- possible :-) - seul ce type d'analyze existe; de toute façon c'est pas
-- le type d'analyze qui sera déterminant ici
SQL> create index evt1_idx on evt1(troll_id) tablespace TEST ;
Index created.
Elapsed: 00:00:00.15
SQL> analyze table evt1 compute statistics for all indexes for all indexed columns ;
Table analyzed.
Elapsed: 00:00:01.14
-- On recupere et on trie par date les evenements pour le troll numéro 5 :
-- le "traceonly" sert - entre autre - à ne pas afficher les lignes a l'écran; on obtient
-- comme ça le temps qu'il faut à la DB pour récupérer les données sur le serveur DB lui-même
SQL> set autotrace traceonly
SQL> select the_date, evt from evt1 where troll_id = 5 order by the_date ;
800 rows selected.
Elapsed: 00:00:00.10
...
-- je passe les stats
...
SQL>
=> Voilà : 10 centièmes de secondes pour récupérer 800 lignes (aux approximations du système près)
-- On cree maintenant une autre table ou on va mettre plus de lignes :
SQL> create table evt3 (the_date date, troll_id number, evt varchar2(40)) tablespace TEST ;
Table created.
Elapsed: 00:00:00.05
-- J'ai fais une procédure qui insere 500000 lignes dans cette table
SQL> exec my_proc
PL/SQL procedure successfully completed.
Elapsed: 00:00:16.50
SQL> commit ;
Commit complete.
Elapsed: 00:00:00.26
SQL> select count(*) from evt3 ;
COUNT(*)
----------
500000
Elapsed: 00:00:00.08
-- Allez, on va en mettre un peu plus quand meme => 500000 c'est pas grand chose quand même !
SQL> insert into evt3 select * from evt3 ;
500000 rows created.
Elapsed: 00:00:07.87
SQL> /
1000000 rows created.
Elapsed: 00:00:52.27
SQL> insert into evt3 select * from evt3 ;
2000000 rows created.
Elapsed: 00:01:58.30
SQL> commit ;
Commit complete.
Elapsed: 00:00:00.04
SQL> select count(*) from evt3 ;
COUNT(*)
----------
4000000
Elapsed: 00:00:52.22
-- Voila : 4 millions, c'est mieux pour comparer avec la table précédente
-- Un ptit index et une analyze sur cette table
SQL> create index evt3_idx on evt3(troll_id) tablespace TEST ;
Index created.
Elapsed: 00:02:36.38
SQL> analyze table evt3 compute statistics for all indexes for all indexed columns ;
Table analyzed.
Elapsed: 00:00:54.07
-- Listons maintenant les 800 evènement du troll 1234 :
SQL> select the_date, evt from evt3 where troll_id = 1234 order by the_date ;
800 rows selected.
Elapsed: 00:00:00.11
...
SQL>
=> 11 centièmes de secondes
Il semble donc que mon affirmation soit vraie : que la table fasse 8000 ou 4 millions de lignes, on met le même temps - sur le server de DB - pour ramener le même nombre de lignes...
Donc des fois je dis des trucs vrais 
A+
OdL |
