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

Requêtes MySQL Discussion :

Requête lente 1 sec


Sujet :

Requêtes MySQL

  1. #1
    Membre actif
    Inscrit en
    Septembre 2004
    Messages
    450
    Détails du profil
    Informations forums :
    Inscription : Septembre 2004
    Messages : 450
    Points : 267
    Points
    267
    Par défaut Requête lente 1 sec
    Bonjour,

    Je n'arrive pas a optimiser cette requête, pouvez vous m'aider s'il vous plait ?

    Traitement en 0.8589 sec. => elle dure presque 1 sec

    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
    EXPLAIN SELECT g. * , c.club AS club, c2.club AS club2, c.dclub AS dclub, c2.dclub AS dclub2, a.daraj_test AS daraj_test, a.araj_test_ch AS araj_test, a.cup AS cup, a.IDcountry AS IDcountry, a.showCountry
    FROM t_game2 AS g
    INNER JOIN t_araj_test_fr AS a ON g.IDaraj = a.ID
    INNER JOIN t_club_fr AS c
    FORCE INDEX ( 
    PRIMARY ) ON g.IDclub = c.ID
    INNER JOIN t_club_fr AS c2 ON g.IDclub2 = c2.ID
    WHERE (
    CONCAT( adate,  ' ', atime ) 
    BETWEEN  '2018-09-23 05:00:00'
    AND  '2018-10-07 09:00:00'
    )
    AND sort >0
    AND a.IDsport =1
    AND a.IDcountry =69
    AND c.display =1
    AND c2.display =1
    ORDER BY sort, araj_test, adate DESC , atime DESC , club
    [ Modifier ] [ Ne pas expliquer SQL ] [ Créer source PHP ]
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    d	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
    1	SIMPLE	c	ALL	PRIMARY	NULL	NULL	NULL	12013	Using where; Using temporary; Using filesort
    1	SIMPLE	g	ref	ccda,IDclub,IDclub2	ccda	4	soccer.c.ID	43	Using where
    1	SIMPLE	c2	eq_ref	PRIMARY	PRIMARY	4	soccer.g.IDclub2	1	Using where
    1	SIMPLE	a	eq_ref	PRIMARY	PRIMARY	4	soccer.g.IDaraj	1	Using where
    Si vous aviez des conseils s'il vous plait ?

    Merci beaucoup pour votre aide

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 763
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 763
    Points : 52 554
    Points
    52 554
    Billets dans le blog
    5
    Par défaut
    1) avez vous besoin de toutes les colonnes de la table t_game2 ? (SELECT g.*) Moins vous en mettrez, plus ça ira vite !
    2) vous avez ajouté un "hint" imposant un chemin pour forcer un index. Êtes vous absolument sûr que ce soit bénéfique ?
    3) CONCAT est une fonction qui renvoie une chaine de caractères et non pas une type temporel. Il serait intéressant de transtyper en datetime
    3bis) le mieux serait de ne pas toucher aux données temporelles filtrées avec le CONCAT car cela rend impossible l'usage d'un index, mais de créer un prédicat "sargable"
    3ter) ne serait-il pas plus judicieux d'avoir un datetime au lieue d'un date et d'un time ?
    4) avez vous les bons index sur toutes les tables ?

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 799
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    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 799
    Points : 34 031
    Points
    34 031
    Billets dans le blog
    14
    Par défaut
    Le problème se situe peut-être là :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    CONCAT( adate,  ' ', atime ) 
    BETWEEN  '2018-09-23 05:00:00'
    AND  '2018-10-07 09:00:00'
    Concaténation en chaîne puis comparaison avec du DATETIME. Pourquoi ne pas avoir fait une colonne DATETIME directement ?
    EDIT : Je n'avais pas vu la réponse de SQLPro... nous sommes en phase !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    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 !

  4. #4
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 379
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 379
    Points : 19 060
    Points
    19 060
    Par défaut
    Salut à tous.

    @ CinPhil : oui, vous avez raison. Le problème se situe bien là, car les deux colonnes ne sont pas sargables.
    Dans un premier temps, vous pouvez faire ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    where  (`adate` = '2018-09-23' and `atime` >= '05:00:00')
       or  (`adate` > '2018-09-23' and `adate` <  '2018-10-07')
       or  (`adate` = '2018-10-07' and `atime` <  '09:00:00')
    Le mieux serait de fusionner vos colonnes `adate` et `atime`en une seule.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  5. #5
    Membre actif
    Inscrit en
    Septembre 2004
    Messages
    450
    Détails du profil
    Informations forums :
    Inscription : Septembre 2004
    Messages : 450
    Points : 267
    Points
    267
    Par défaut
    Citation Envoyé par CinePhil Voir le message
    Le problème se situe peut-être là :

    Concaténation en chaîne puis comparaison avec du DATETIME. Pourquoi ne pas avoir fait une colonne DATETIME directement ?
    EDIT : Je n'avais pas vu la réponse de SQLPro... nous sommes en phase !
    Je n'ai pas fait de colonne DATETIME directement, car je reprends un site racheté, mais c'est prévu, juste le temps de revoir la bdd en détail et cibler les requêtes posant problèmes.

    Merci

  6. #6
    Membre actif
    Inscrit en
    Septembre 2004
    Messages
    450
    Détails du profil
    Informations forums :
    Inscription : Septembre 2004
    Messages : 450
    Points : 267
    Points
    267
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    1) avez vous besoin de toutes les colonnes de la table t_game2 ? (SELECT g.*) Moins vous en mettrez, plus ça ira vite !
    2) vous avez ajouté un "hint" imposant un chemin pour forcer un index. Êtes vous absolument sûr que ce soit bénéfique ?
    3) CONCAT est une fonction qui renvoie une chaine de caractères et non pas une type temporel. Il serait intéressant de transtyper en datetime
    3bis) le mieux serait de ne pas toucher aux données temporelles filtrées avec le CONCAT car cela rend impossible l'usage d'un index, mais de créer un prédicat "sargable"
    3ter) ne serait-il pas plus judicieux d'avoir un datetime au lieue d'un date et d'un time ?
    4) avez vous les bons index sur toutes les tables ?

    A +
    Pour la table t_game2 ? (SELECT g.*) en effet je n'ai pas besoin de toutes les colonnes, je vais faire un tri.
    Pour le FORCE INDEX, je vais l'enlever, j'avais des test, et j'ai complètement oublier de l'enlever, cela ne m'a rien apporté
    Pour CONCAT je l'ai enlever et mis temporairement la solution de Artemus24
    Je vais opter pour le datetime plus tard, juste le temps de faire le tour de la bdd ( un site web que je viens de reprendre )
    Pour les index je pense que oui

    Merci

  7. #7
    Membre actif
    Inscrit en
    Septembre 2004
    Messages
    450
    Détails du profil
    Informations forums :
    Inscription : Septembre 2004
    Messages : 450
    Points : 267
    Points
    267
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Salut à tous.

    @ CinPhil : oui, vous avez raison. Le problème se situe bien là, car les deux colonnes ne sont pas sargables.
    Dans un premier temps, vous pouvez faire ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    where  (`adate` = '2018-09-23' and `atime` >= '05:00:00')
       or  (`adate` > '2018-09-23' and `adate` <  '2018-10-07')
       or  (`adate` = '2018-10-07' and `atime` <  '09:00:00')
    Le mieux serait de fusionner vos colonnes `adate` et `atime`en une seule.

    @+

    Merci pour la solution , je vais plus tard fusionner `adate` et `atime`en une seule.

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

Discussions similaires

  1. SQL_NO_CACHE et requêtes lentes
    Par bigsister dans le forum Requêtes
    Réponses: 5
    Dernier message: 20/03/2012, 12h39
  2. Requête lente sur une grosse table
    Par mr_keyser dans le forum PostgreSQL
    Réponses: 7
    Dernier message: 12/12/2007, 19h15
  3. Requête lente: besoin de conseils
    Par ctobini dans le forum PostgreSQL
    Réponses: 1
    Dernier message: 21/10/2007, 08h23
  4. Requête lente que ne n'arrive pas à optimiser
    Par Christophe Charron dans le forum Requêtes
    Réponses: 4
    Dernier message: 07/06/2007, 09h48
  5. requète lente (10 min)
    Par jfwatteau dans le forum Access
    Réponses: 3
    Dernier message: 27/12/2005, 09h47

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