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

Si vous joignez une capture d'écran de vos plans de requête et une trace de Profiler, je me ferai un plaisir de vous dire lequel est le plus rapide. Sinon, il n'y a pas assez d'informations pour répondre à la question.

Mon intuition est que les deux ont des performances très similaires dans SQL Server et que SQL Server optimise les deux pour utiliser le même plan de requête, mais qui sait, il est possible qu'une jointure de cinquante tables rende l'optimiseur un peu fou.

Je m'en tiendrai en général à la sémantique JOIN car je la trouve plus facile à lire et à maintenir. La jonction croisée est très sujette aux erreurs et extrêmement rare.

Answer 2

Merci pour vos réponses.

Je n'ai pas accès à Query Analyser car je suis en train de transférer cette base de données de MS Access, où je faisais un prototype rapide, vers MySQL. Je crois que Query Analyser n'est seulement disponible sur SQL Server mais je peux me tromper, donc je ne peux pas joindre ma trace Profiler.

Chaque table est distincte (c'est-à-dire que les valeurs qu'elle contient sont uniques, même si les noms des colonnes sont identiques) et est utilisée séparément pour générer d'autres objets, mais j'ai besoin d'exécuter occasionnellement un résumé qui rassemble les lignes de chaque table. Je pense donc que j'ai besoin de 50 tables, bien que je n'aie pas développé l'ensemble du schéma, et je vais donc me pencher sur la question. (p.s. Je suis novice en matière de bases de données et de SQL, mais je ne suis pas novice en matière de programmation). Je dois également tenir compte des ramifications sur la taille de la mémoire si je devais mettre toutes les informations dans une table alors que seule une petite partie de celle-ci sera utilisée à chaque fois.

Toutefois, d'après ce que j'ai compris, la différence ne devrait pas être si importante puisque les deux déclarations seront probablement compilées dans la même requête interne. J'ai posé la question pour savoir si les données internes seront différentes. Je vais effectuer des tests sur des données réelles pour le savoir.

D'ailleurs, les performances des deux déclarations seront-elles différentes si nous prenons en compte les requêtes simultanées de plusieurs utilisateurs ?

Answer 3

Vous ne précisez pas le volume attendu de vos tables, mais sachez que si les requêtes sont optimisées en fonction de plans de requête différents, ce qui est le plus rapide avec 100 lignes dans votre table peut ne pas être le même que lorsque vous avez 100 000 lignes ou plus.

En fait, il n'y a généralement que peu d'avantages à optimiser de manière obsessionnelle les requêtes utilisant des tables de moins de 10 000 enregistrements, à condition que les index et les requêtes soient conçus de manière raisonnable. Cependant, autour de 100 000 enregistrements, les performances des requêtes mal optimisées commencent à se dégrader, généralement de manière catastrophique. Le chiffre exact dépend de la taille des lignes et de la quantité de mémoire dont dispose le serveur, mais il n'est pas rare de voir les performances se dégrader d'un ordre de grandeur ou plus pour un doublement de la taille de la table.

En règle générale, la meilleure stratégie consiste à ne pas perdre de temps avec des requêtes mineures sur des tables de petite taille, l'effort peut généralement être dépensé de manière plus rentable dans d'autres domaines. Cependant, il convient d'optimiser de manière agressive toutes les requêtes qui sont exécutées sur vos tables principales si celles-ci sont susceptibles d'augmenter de plus de 10 000 lignes. En général, cela signifie qu'il faut utiliser une instance QA et charger 10 fois le volume prévu pour vérifier le comportement réel.

Answer 4

L'optimisation de l'ordre de jonction prend un temps exponentiel. Chaque moteur de base de données sélectionne simplement un petit nombre d'ordres de jointure possibles et estime le meilleur d'entre eux.

On a l'impression que vous voudrez toujours join ... on c*1*.Date = c*n*.Date pour tous n .

Vous voudrez également vous débarrasser du schéma de base de données extrêmement étrange que vous avez.

Answer 5

Que s'est-il passé lorsque vous avez essayé ?

Sérieusement, l'analyseur de requêtes dispose d'un petit minuteur pour une raison bien précise. Différentes structures de requête donnent parfois des temps d'exécution très différents, souvent sans raison intuitive.

Rédigez les deux requêtes. Testez-les. Puis revenez et répondez à votre propre question.