IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration MySQL Discussion :

Requête lente sur une table


Sujet :

Administration MySQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Inscrit en
    Août 2006
    Messages
    188
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 188
    Par défaut Requête lente sur une table
    Bonjour,

    toutes les requêtes portant sur une table de ma base de données sont lentes et je pense qe c'est dû au fait qu'il y a beaucoup trop de données dedans mais n'en suis pas sûr.

    Est-ce que vous pourriez jeter un coup d'oeil à la pièce jointe et me dire ce que vous en pensez ? C'est une copie d'écran de l'onglet "Information" de ma table dans Toad.

    Merci.

  2. #2
    Expert éminent
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 818
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 818
    Billets dans le blog
    14
    Par défaut
    745 008 lignes, c'est pas mal mais j'ai déjà travaillé avec des tables presque dix fois plus grosses.

    1,6 Go de données c'est pas mal non plus mais ce n'est pas impossible à traiter.
    29 Mo d'index, ce n'est peut-être pas beaucoup par rapport à la taille de la table.

    Il faudrait nous donner le SHOW CREATE TABLE de cette table.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole, en retraite... mais toujours Autoentrepreneur à l'occasion.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  3. #3
    Membre confirmé
    Inscrit en
    Août 2006
    Messages
    188
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 188
    Par défaut
    le voici :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
     
    CREATE TABLE `table` (
      `operation_type` varchar(8) NOT NULL default '',
      `site` varchar(50) default NULL,
      `site_code` varchar(20) default NULL,
      `dept` varchar(100) default NULL,
      `dept_code` varchar(20) default NULL,
      `n_client` varchar(10) NOT NULL default '0',
      `ref_option` varchar(50) NOT NULL,
      `code` char(3) NOT NULL default '',
      `qte` tinyint(2) NOT NULL default '1',
      `mtht` decimal(12,3) NOT NULL default '0.000',
      `tva` decimal(4,2) default '0.00',
      `ident_cc2` varchar(8) NOT NULL default '',
      `date_enr` datetime NOT NULL default '1000-01-01 00:00:00',
      `cc_init` varchar(100) NOT NULL,
      `histo_valideur` longtext NOT NULL,
      `dernier_valideur` varchar(10) NOT NULL default 'nonvalidé',
      `date_valideur` datetime default NULL,
      `ident_integrateur` varchar(20) NOT NULL default '',
      `date_integration` datetime default NULL,
      `valide` tinyint(1) unsigned zerofill NOT NULL default '0',
      `refusN4` tinyint(4) NOT NULL default '0',
      `integre` tinyint(1) unsigned zerofill NOT NULL default '0',
      `rejete` tinyint(1) unsigned zerofill NOT NULL default '0',
      `plateforme` varchar(15) NOT NULL default '',
      `ref_lot` varchar(20) NOT NULL default '0',
      `ocv04` longtext NOT NULL,
      PRIMARY KEY  (`n_client`,`date_enr`),
      KEY `date1` (`date_valideur`),
      KEY `ident_cc2` (`ident_cc2`),
      KEY `site` (`site`),
      KEY `date2` (`date_enr`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

  4. #4
    Membre chevronné
    Profil pro
    Inscrit en
    Février 2005
    Messages
    390
    Détails du profil
    Informations personnelles :
    Localisation : France, Vaucluse (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : Février 2005
    Messages : 390
    Par défaut
    salut.


    Je pense qu'il y a un souci de conception au niveau de ta base. J'espere que tu n'as rien codé avec cette table.

    Mettre tout les données dans une seule et même table ne permets pas vraiment d'exploiter comme il faut tes données.

    Il va falloir éclater cette table nommé "table" en facilement 4 a 5 tables.

    a premiere vue, je vois bien: "client", "service", "contact", "facture" ou "facturation" ... puis apres si tu veux aller plus loin article. pour la facturation tu fais une relation n:n avec contact et comme champ date, statut ect.


    aprés j'y ai pas passé beaucoup de temps. et je suis pas trés bon en modelisation.


    bonne chance.

  5. #5
    Expert éminent
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 818
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 818
    Billets dans le blog
    14
    Par défaut
    Effectivement, il y a des choses à revoir !

    On peut savoir de quoi il s'agit parce que les libellés des colonnes ne sont pas hyper clairs et peuvent être interprétés de plusieurs façons.

    1) Ne pas appeler une table 'table'
    Les tables et les colonnes ne doivent pas être appelés d'un mot du langage SQL. Ca peut provoquer des erreurs.

    2) La clé primaire composée de deux colonnes laisse à penser qu'il s'agit d'une table issue d'une association porteuse de données.
    Il s'agit d'enregistrements relatifs à des clients ?
    Des enregistrements de quoi ?
    De plus, cette clé primaire, composée d'une colonne de type VARCHAR(10) et d'une de type DATETIME, n'est pas optimale.
    Une bonne clé issue d'une entité du MCD est de type INTEGER.
    Par voie de conséquence, les clés des tables associatives sont composées de clés étrangères de même type que les identifiants auxquels elles font référence et seront aussi de type entier. Il est toutefois possible qu'une colonne de type DATE participe à la clé primaire d'une table associative, comme cela semble être le cas ici.

    3) Si j'en crois son nom, la colonne operation_type est censée contenir un type d'opération. Là encore, il devrait s'agir d'une clé étrangère faisant référence à l'identifiant de type entier d'une table des types d'opération.

    4) Les colonnes 'site' et 'site_code' représentent probablement la même donnée. Il y a donc doubon d'information dans la table. Il devrait y avoir une table des sites et ici une clé étrangère faisant référence à l'identifiant du site.

    J'espère que vous avez compris le principe.

    Modélisez vos données en utilisant par exemple la méthode Merise et normalisez au maximum votre modèle de données.

    Nous pourrons vous y aider dans le forum Schéma.

    Bon courage !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole, en retraite... mais toujours Autoentrepreneur à l'occasion.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  6. #6
    Membre confirmé
    Inscrit en
    Août 2006
    Messages
    188
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 188
    Par défaut
    Bonjour,

    merci pour ces réponses, je vais revoir entièrement cette table, je me disais bien qu'il y avait un gros souci

    Par curiosité j'aimerais bien savoir comment on sait qu'il n'y a quasiment plus de places dans une table, et surtout qu'est-ce qu'on fait dans ces cas-là ? Je pense que ça ne doit pas arriver souvent mais j'aimerais quand même connaître la solution..

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 5
    Dernier message: 04/05/2009, 14h56
  2. Query tres lent sur une table vide ?!
    Par CAML dans le forum SQL
    Réponses: 6
    Dernier message: 24/04/2009, 15h08
  3. Problème de requête Access sur une table Oracle
    Par Poulki dans le forum Requêtes et SQL.
    Réponses: 5
    Dernier message: 31/01/2008, 16h57
  4. Requête lente sur une grosse table
    Par mr_keyser dans le forum PostgreSQL
    Réponses: 7
    Dernier message: 12/12/2007, 19h15
  5. Réponses: 4
    Dernier message: 27/12/2006, 21h53

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo