Table de 1 Go et recherche

[aodot]

Bonjour,

Je viens d'importer dnas une base de données un table de plus de 8 000 000 d'entrées (pays et villes du monde). Quand je fais une recherche (via une requete SQL en PHP) dans cette table cela prend 15 secondes avant de me sortir un résultat, je pense que cela est normal du fait du nombre d'entrées...

J'ai donc scinder mes requetes en deux :

1) je cherche le pays

2) puis je cherche les villes liées à ce pays

Mais j'ai toujours le même problème.

Il y a t il une solution ou un retour d'expérience sur ce sujet ou un conseil ?

Un grand merci par avance.

COrdialement.

[Portekoi]

Bonjour,

As tu créé des index? Un index sur le pays et un index sur "Pays - Ville" ?

Portekoi

[SStephane]

Comme te le dis portekoi, indexer est la bonne solution, si ta table est normalement indéxé (avec des clés étrangères de type int référencées, pas juste un truc de liaison), ta recherche sera beaucoup, beaucoup plus rapide.

Si des recherches sont à prévoir sur le nom des pays/villes, tu peux éventuellement indéxer les colonnes intitulé mais attention, c'est pas franchement terrible, et il faut le faire selon l'utilisation qui en est faite :

• Si aucune recherche n'est effectuée sur les intitulés, il ne faut rien indexer mais simplement ajouter les clés étrangeres entre ville et pays (les clés primaires et étrangères sont des index implicites),
  
• Si ces recherches se font sur les intitulés dans le cadre, par exemple d'autocomplétion d'un champ ( LIKE 'machin%'), n'indexer que les 2,3 ou 4 premières lettres peut être suffisant,
  
• Si la recherche peut s'effectuer sur toute ou partie de cet intitulé (LIKE '%machin%', indexer la colonne entière est peut-être pour toi la bonne solution.
  

Si tu n'es pas familier des requêtes à effectuer pour indéxer, les clients lourds pour la majorité des SGBD permettent de faire cela, et il me semble que phpmyadmin aussi (à confirmer).

Un index sur une string prends plus de place, c'est donc avec parcimonie qu'il faut les utiliser