Discussion :

[Tardiff Jean-François]

Bonjour,

J'ai une table traitant de nombreuses années à raison d'un enregistrement par jour (plus de 5500 enregistrements), avec de trés nombreux champs ( plus de 150) .

Lorsque je me connecte sur cette table (Select * from TypeA) le temps d'attente est de 25 à 30 secondes avant que la connexion ne soit effective.

Si je réduit le nombre d'enregistrements, le temps de connexions tombe à moins de une seconde.

Si je regarde le trafic réseau, je me rends compte que tous les enregistrements ne sont pas rapatriés sur le client (ce qui est normal).

Une autre table (calendrier) avec autant d'enregistrements ce connecte en mois d'une seconde.

J'utilise Delphi, Adoquery et le driver "MySql ODBC 3.51".

Comment pourrais je réduire le temps nécessaire pour me connecter ?

Merci

[qi130]

Tu parles de 150 champs, mais combien d'octets représente une ligne ? (150 champs en integer <<< 150 champs en varchar(200) ): ça peut générer du traffic réseau.

Pour diminuer le temps d'attente (et pas de connexion), tu peux commencer par rapatrier les 50 ou 100 premières lignes (clause LIMIT), puis demander les suivantes en cas de besoin.

[Tardiff Jean-François]

La plupart des champs sont des Double, decimal et integer.
Il y a un LongText (vide dans plus de 99% des cas).

Mais je ne pense pas que se soit dus au trafic réseaux. Si je compare le trafic réseau lors de l'ouverture de cette table, et le trafic lors de l'ouverture d'autres tables (s'ouvrant en moins de 1 seconde), je ne vois pas de trafic plus important. Par contre je vois 1 pic (trés court) lors du open, et un autre pic lorsque le open est fait (30 seconde plus tard). Les 2 pics réunis ne semblent pas ecxesif. en comparaison du pic unique obtenue par l'ouverture d'une autre table.

[dest]

Une idée: rapatrier uniquement les champs utiles et rajouter des index pour faciliter la recherche.

[Tardiff Jean-François]

Mas fois j'ai déjà des index, et je suis en train de modifier le programme pour ne charge qu'une fenêtre de plus ou moins 100 jours. Si je demande une date aux dela, je fermerais la table et la ré-ouvrirais avec une nouvelle fourchette de date.

Le problème et que j'ai peur qu'une autre table ne me fasse le même problème au bout d'un certain temps. Si je comprend la cause théorique, je pourrais peut être régler le problème à la base et éviter tous risque.

[qi130]

Pas d'ORDER BY dans ton select * ?

La table est-elle désorganisée ?

[Tardiff Jean-François]

Non pas de Order, Un simple select simple.

La table à un index primaire, même les enregistrements ont été créer dans l'ordre de la clé primaire. (Ce qui en principe ne change rien, car la table doit être organisé en fonction de cette clé)

C'est franchement le truc bizard. Facil à contourner par programmation, mais si cela ce produit avec une autre table si le prog. est chez un client.

Bon c'est vrai que c'est moyennement pénalisant (1 connection à la table dans l'application), par contre un type comme mon patron détruit le process si le programme n'est pas lancer dans la minute qui suit. Et les client à qui le prog. sont destiné ne semblent pas plus patient.

[Alexandre T]

Plusieurs pistes :
1- Evitez le SELECT *. Et ne sélectionnez que les champs à afficher.
2- Lancez une analyse de table et un optimisation de la table.
3- Evitez les connexions ODBC plus lente et préférez des connexions natives
4- Pour éviter de vous interroger sur les problèmes de réseaux et autres mesurez les performances de votre requête en vous connectant directement via la console mysql sur le serveur, en lançant la requête (le temps de réponse sera alors afiché clairement en milliseconde)
5- Utilisez la commande EXPLAIN pour savoir si vous index sont bien utilisés.

7.2.1. Syntaxe de EXPLAIN (Obtenir des informations sur les SELECT)
7.2.2. Mesurer les performances d'une requête

[Tardiff Jean-François]

Bonjour,

La console MySql me donne environ le même temps, mais elle me renvoi tout les information à l'écran. Alors que théoriquement je n'ai fait que me connecter sans parcourir le résultat de la requête.

Le 'select * ' m'est malheureusement indispensable. Par contre j'ai limité le nombre d'enregistrement directement accessible sans avoir a reinitialiser la query.

La connections ODBC est une demande, je ne peux pas l'éviter.

A priori l'index utilisé est le bon. Par contre je note l'ordre explain pour d'autre requêtes (dans les éditions)


Pour m'en sortir, J'ai remplacer les "select * from TYpea" par "Select * From TypeA where (MasterKey >= D1) et (MasterKey <= D2)" avec D1 et D2 égale a la date du jour + ou - 100 jour. La le temps de réponse de la connections est de quelques millisecondes. Lorsque j'essaye de traiter une date, je vérifie que mas date est dans la fourchette; si elle n'y est pas je ferme la requête, et la rouvre en ayant déplacer la fourchette de date.

Le problème est donc résolu de manière basic. Sauf pour les éditions qui peuvent se faire sur X années (bonjour la lisibilité des résultats avec un listing de 15 à 20 pages), mais la l'attente est noyé dans les traitements des information et ce n'est pas trop gênant.

Pour le reste j'essaye de comprendre le pourquoi du problème de façon à éviter qu'il ne se reproduise (sur cette appli. ou une autre).

Enfin, même sans réponse, je vais arrêter mas demande. Inutile d'embéter les autres alors que le programme fonctionne. Par contre je vais continuer d'essayer de comprendre par mois même.

Merci a tous pour les réponses.

[Alexandre T]

Le gain sera léger, mais préférez la requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Select * From TypeA where MasterKey BETWEEN D1 AND D2

à la requête

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Select * From TypeA where (MasterKey >= D1) et (MasterKey <= D2)

[Tardiff Jean-François]

Merci pour l'info.
Je croyais BETWEEN reserver au numériques, et ne l'ai donc pas utilisé.