Quelle est l'instruction SQL la plus rapide ?

Question

Quelle est l'instruction SQL la plus rapide ?

SELECT TOP 2 c1.Price, c2.Price, ..... c49.Price, c50.Price
FROM Table1 AS c1, Table2 AS c2, ..... Table49 AS c49, Table50 AS c50
WHERE c1.Date = c2.Date AND c2.Date = c3.Date ..... c49.Date = c50.Date
ORDER BY c1.ID DESC

        OR

SELECT TOP 2 c1.Price, c2.Price, ..... c49.Price, c50.Price
FROM (Table1 AS c1 
 INNER JOIN (Table2 AS c2 
    ........
  INNER JOIN (Table49 AS c49
   INNER JOIN Table50 AS c50
  ON c49.Date = c50.Date)
    ........
 ON c2.FullDate__ = c3.FullDate__)
ON c1.FullDate__ = c2.FullDate__)
ORDER BY c1.ID DESC";

J'ai besoin d'extraire 2 lignes de chaque tableau pour produire un résumé périodique. Quelle est l'instruction la plus rapide ?

Answer 1

Ce qui est plus rapide, c'est de ne pas avoir 50 tables au départ. Joindre 50 tables peut être acceptable, mais c'est une conception très contre-intuitive et ce n'est probablement pas la solution la plus facile à maintenir.

Ne pouvez-vous pas stocker vos données dans les lignes (ou les colonnes) d'une seule (ou de moins de) table(s) plutôt que dans 50 tables ?

Answer 2

Il est généralement préférable de savoir où, mais la meilleure façon de procéder est la suivante au cas par cas et le lancer dans le profiler, ou plus simplement encore afficher le plan d'exécution . Les spécialistes ont souvent des avis très tranchés sur l'approche la plus rapide/la meilleure en théorie, mais rien ne remplace le réglage effectif en fonction des données que vous traitez réellement, car les théories applicables changent en fonction de la charge de données.

Si vous n'avez pas données réelles dans votre application, essayez de créer des données réalistes sur le stress. Ces données continueront à être utiles pour les tests. Prévoyez ensuite du temps pour effectuer des réglages une fois que l'application sera opérationnelle.

Answer 3

Vous constaterez probablement que le moteur d'optimisation SQL générera la même requête interne (si la logique est la même) et qu'il n'y aura donc pas de différence.

Comme d'autres l'ont mentionné, passez le tout au crible d'un profileur (tel que Query Analyzer) pour déterminer la différence (s'il y en a une).

Answer 4

Toute cette discussion sur la réduction du nombre de tables m'a fait réfléchir (merci MarkR). J'ai la documentation de MySQL pendant les deux dernières heures et j'ai réalisé qu'une qu'une meilleure solution serait de créer une nouvelle table récapitulative qui contiendrait les résultats initiaux. Ensuite, je créerais un déclencheur qui mettrait à jour la nouvelle table à chaque fois qu'une insertion a lieu dans l'une des tables qui est toujours touchée.

Une autre idée à laquelle j'ai pensé est de créer une vue de la requête. Cependant, il semble que MySQL exécute la requête sous-jacente dans une vue à chaque fois qu'elle est appelée. Ai-je raison ? Existe-t-il un moyen de faire en sorte que MySQL stocke la table de résultat d'une vue pré-exécutée, puis d'utiliser un déclencheur pour indiquer à la vue quand mettre à jour la table ? Existe-t-il un SGBDR qui fait cela ?

Answer 5

Normalement, la base de données optimise les deux déclarations, de sorte que la différence n'est pas si importante. Mais vous pouvez le vérifier en comparant le plan d'explication des deux requêtes.

Une chose qui pourrait éventuellement optimiser la requête avec les jointures (je ne l'ai pas vérifié) est d'avoir des contraintes supplémentaires (contraintes non jointes) dans la déclaration de jointure. Bien que ce style ne soit pas recommandé car il ne sépare pas clairement les conditions de jointure des autres conditions.

Par exemple :

select *     
   from A a 
       join B b on b.x = a.y    
       where b.z = 'ok';

peut s'écrire comme suit

select * 
   from A a 
       join B b on b.x = a.y and b.z = 'ok';