Requête lente lors de l'utilisation de la COMMANDE PAR

Voici la requête (la plus grande table a environ 40 000 lignes)

SELECT
  Course.CourseID,
  Course.Description,
  UserCourse.UserID,
  UserCourse.TimeAllowed,
  UserCourse.CreatedOn,
  UserCourse.PassedOn,
  UserCourse.IssuedOn,
  C.LessonCnt
FROM
  UserCourse
INNER JOIN
  Course
USING(CourseID)
INNER JOIN
(
  SELECT CourseID, COUNT(*) AS LessonCnt FROM CourseSection GROUP BY CourseID
) C
USING(CourseID)
WHERE 
  UserCourse.UserID = 8810

Si je l'exécute, il s'exécute très rapidement (.05 secondes environ). Il retourne 13 lignes.

Quand j'ajoute un ORDER BY clause à la fin de la requête (commande par colonne) la requête prend environ 10 secondes.

Je suis en utilisant cette base de données en production maintenant, et tout fonctionne bien. Tous mes autres requêtes sont rapides.

Toutes les idées de ce que cela pourrait être? J'ai couru à la requête MySQL Query Browser, et à partir de la ligne de commande. Les deux endroits, il a été très lente avec le ORDER BY.

EDIT: Tolgahan ALBAYRAK solution fonctionne, mais quelqu'un peut-il expliquer pourquoi cela fonctionne?

Pourquoi ça marche? une sous-requête est le résultat d'un ensemble de résultats, et la commande d'un jeu de résultats est beaucoup plus rapide que d'avoir le défaut d'exécution de la requête avez compter de la commande, le long de la manière.

OriginalL'auteur | 2009-05-19

mysql sql-order-by

17

peut-être que cela aide:
```
SELECT * FROM (    
     SELECT
      Course.CourseID,
      Course.Description,
      UserCourse.UserID,
      UserCourse.TimeAllowed,
      UserCourse.CreatedOn,
      UserCourse.PassedOn,
      UserCourse.IssuedOn,
      C.LessonCnt
    FROM
      UserCourse
    INNER JOIN
      Course
    USING(CourseID)
    INNER JOIN
    (
      SELECT CourseID, COUNT(*) AS LessonCnt FROM CourseSection GROUP BY CourseID
    ) C
    USING(CourseID)
    WHERE 
      UserCourse.UserID = 8810
) ORDER BY CourseID
```
Hein, ça fonctionne (en fait exécuter rapide). Savez-vous pourquoi? Je n'ai jamais eu à le faire avant.
40k n'est pas que le nombre d'enregistrements; ont généralement à faire face à des millions soyour kilométrage peut varier, mais cela peut aider à améliorer la performance sur ce que les jointures sont faites sur un jeu de données réduit. ... From (Select * from UserCourse Où UserID = 8810 ) UserCourse
le ralentissement vient parce que c'est probablement le choix de faire de la commande avant de faire la jointure. Faire de l'ordre dans une requête externe, ce qui le force à commander uniquement les éléments sélectionnés.
tvanfosson, j'ai toujours pensé que l'ORDRE EN a été traitée après que les résultats ont été retournés. Je suppose que ce n'est pas nécessairement le cas. Je vais étudier un peu plus. Merci.

OriginalL'auteur Tolgahan Albayrak
7

Est la colonne que vous souhaitez commander par indexé?

Indexation considérablement accélère la commande et de filtrage.

l'op mentionné à l'aide de n'importe quelle colonne dans l'ordre réduit les performances
Toute la colonne, y compris les colonnes indexées, le faire fonctionner lente.

OriginalL'auteur ceejayoz
2

Vous de la sélection de "UserCourse" qui je suppose est une réunion de la table entre les plats et les utilisateurs (plusieurs à Plusieurs).
Vous devriez indice de la colonne que vous avez besoin de commander par, dans la "UserCourse" de la table.

Supposons que vous voulez "commande par CourseID", alors vous avez besoin de l'indexer sur UserCourse table.

De la commande par tout autre colonne qui n'est pas présent dans l'assemblage de la table (c'est à dire UserCourse) peuvent exiger davantage de dénormalisation de l'indexation et de sur le de rejoindre table être optimisé pour la vitesse;
En d'autres termes, vous devez avoir une copie de cette colonne dans l'assemblage des tables et des index.

P. S.
La réponse donnée par Tolgahan Albayrak, bien que correct pour cette question, ne serait pas d'obtenir le résultat souhaité, dans les cas où l'on est en train de faire une "LIMITE x de la requête".

OriginalL'auteur Guy
1

Réaliser réponse est trop tard, mais j'ai juste eu un problème similaire, l'ajout de la commande par l'augmentation de la durée de la requête de quelques secondes à 5 minutes et après avoir essayé la plupart des autres suggestions pour l'accélérer, a remarqué que le /tmp fichiers où arriver à être 12G pour cette requête. Modifié la requête telle qu'un varchar(20000) champ retourné a "trim("ed et le rendement amélioré de façon spectaculaire (secondes). Donc je suppose que sa vaut la peine de vérifier si vous êtes le renvoi de grands varchars comme une partie de votre requête et, dans l'affirmative, de les traiter (peut-être sous-chaîne(x, 1, length(x))?? si vous ne voulez pas de garniture.
La requête a été de retour de 500 k lignes et le fichier /tmp indiqué que chaque ligne à l'aide d'environ 20k de données.

OriginalL'auteur aronp
0

Avez-vous mis à jour les statistiques sur votre base de données? Je suis tombé sur quelque chose de similaire sur le mien où j'ai eu 2 requêtes identiques où la seule différence est une lettre majuscule et on est rentré en 1/2 seconde et l'autre a pris près de 5 minutes. Mise à jour des statistiques résolu le problème

OriginalL'auteur Fry
0

Une question semblable a été posée avant ici.

Il pourrait vous aider. Fondamentalement, il décrit à l'aide d'indices composites et comment l'ordre par les œuvres.

OriginalL'auteur northpole
0

Aujourd'hui j'ai été en cours d'exécution dans un même genre de problème. Dès que j'ai été tri le jeu de résultats en un champ de la table jointe, la totalité de la requête a été horriblement lent et a pris plus d'une centaine de secondes.

Le serveur était en cours d'exécution MySQL 5.0.51 a et par chance, j'ai remarqué que la même requête courait aussi vite qu'il devrait les avoir toujours fait sur un serveur avec MySQL 5.1. Lorsque l'on compare les explique pour cette recherche, j'ai vu que de toute évidence, l'utilisation et la manipulation des indices a beaucoup changé (à moins de 5,0 -> 5.1).

Donc, si vous rencontrez un tel problème, peut-être que votre résolution est tout simplement de la mise à niveau de votre serveur MySQL

OriginalL'auteur Dominik Jungowski

Vous devez vous connecter pour publier un commentaire.