Petits soucis SQL - optimiser les requêtes

[lpgc]

bonjour,

sans trop rentrer dans les détails ... j'affiche dans une listbox 10.000 lignes
en provenance d'une jointure sur 2 tables contenant un ordre decroissant sur l'une des colonnes

Et cela prenait du temps ... trop de temps
J'ai alors vérifié le temps utilisé pour la requete proprement dite
et le parcours du recordset pour constituer la liste

grosses surprises 15 sec pour la requête et 15 sec pour la liste

En vérifiant les tables j'avais une cléprimaire + un index sur la même colonne ...
la suppression de l'index a déjà diviser le temps par 2 ... surprenant
Mais 7 sec c'est encore de trop
j'ai rajouté un index sur la date de tri ... et là je suis passé à moins de 1 sec

( je me demande s'il existe des outils SQL permettant d'optimiser les requêtes ...
dans le sens où l'outil nous dirait qu'il manque un index sur telle colonne ... )

Pour le remplissage de la liste ... là je ne crois pas que l'on peut faire grand chose ... du moins je le suppose

J'ai tout de même limité la liste à 500 ( LIMIT 500; ) ... dans certains cas

Je suppose que tout ceci dépend principalement de la charge du serveur
... En fait je n'ai peut-être rien amélioré ... Mais çà semble avancer un peu plus vite

[calimo]

bonjour,

sans trop rentrer dans les détails ... j'affiche dans une listbox 10.000 lignes

Qu'est-ce que tu appelles une "listbox" au juste ?

En vérifiant les tables j'avais une cléprimaire + un index sur la même colonne ...
la suppression de l'index a déjà diviser le temps par 2 ... surprenant
Mais 7 sec c'est encore de trop
j'ai rajouté un index sur la date de tri ... et là je suis passé à moins de 1 sec

On dirait du MySQL... c'est bien ça ?
C'est un des gros problèmes de MySQL amha, il faut tout optimiser manuellement et avec une doc obscure... essaye quand même de lire ça : http://dev.mysql.com/doc/refman/5.0/fr/ ... ation.html (7.2 en particulier).
(Attention, ils vont essayer de te faire comprendre qu'il ne faut pas utiliser les join, les clés étrangères ou les transactions, c'est une question de philosophie...)


Après s'il y a 10000 lignes, il faut aussi penser au temps de téléchargement et d'affichage dans le navigateur

[lpgc]

Qu'est-ce que tu appelles une "listbox" au juste ?

(Attention, ils vont essayer de te faire comprendre qu'il ne faut pas utiliser les join, les clés étrangères ou les transactions, c'est une question de philosophie...)

listbox ... oui un select-option mais pas un combo ... sous forme de liste

le join à l'air d'être assez rapide ... c'est plutot au niveau de l'ordre DESC que çà bloque parfois ...

l'ordre ASC à l'air plus rapide ... je me demande si je ne vais pas essayer de remplir la liste dans l'autre sens
( lire le recordset en utilisant le previous au lieu du next record )

Merci. Je vais regarder le lien ce soir et refaire quelques tests

[Benoit]

Sinon il faut quand même savoir qu'une listbox de 10000 lignes c'est du très mauvais design

Non seulement ça va être très lent sur le serveur mais aussi à afficher dans le navigateur, sans parler d'essayer de sélectionner une valeur dedans. Dans ce genre de cas, mieux vaut une recherche bien faite, ou pourquoi pas une autocomplétion dynamique (via XMLHttpRequest par exemple).

[lpgc]

Au départ, j'affichais la liste complète des DVDs ... mais c'est vrai que ce n'est pas très utile

Je me limite maintenant aux 500 derniers entrés quand je mets une *
dans le titre ... ( en ajoutant LIMIT 500 dans la requête SQL )
... il a fallut le temps pourque je découvre l'astuce du LIMIT

sinon c'est effectivement de cette façon que cela fonctionne, dynamiquement lorsque je tape quelques mots

Par contre le select-option supporte assez bien les grands nombres de lignes et je trouve d'ailleur
qu'il s'intégre parfaitement dans la page et que son utilisation est assez fluide

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12