web-dev-qa-db-fra.com

Accélérer les jointures internes entre une grande table et une petite table

Cela peut être une question stupide, mais cela peut éclairer le fonctionnement interne des jointures.

Disons que j'ai une grande table L et une petite table S (100 000 lignes contre 100 lignes).

Y aurait-il une différence de vitesse entre les deux options suivantes?:

OPTION 1:                 OPTION 2:
---------                 ---------
SELECT *                  SELECT *
FROM L INNER JOIN S       FROM S INNER JOIN L
ON L.id = S.id;           ON L.id = S.id;

Notez que la seule différence est l'ordre dans lequel les tables sont jointes.

Je me rends compte que les performances peuvent varier entre différents langages SQL. Si oui, comment MySQL se comparerait-il à Access?

sqlquery-optimization
34
Zaid

Non, la commande n'a pas d'importance.

Presque tous les SGBDR (tels que MS Access, MySQL, SQL Server, Oracle, etc.) utilisent un optimiseur basé sur les coûts basé sur les statistiques des colonnes. Dans la plupart des situations, l'optimiseur choisira un plan correct. Dans l'exemple que vous avez donné, la commande n'aura pas d'importance (à condition que les statistiques soient à jour).

Pour décider de la stratégie de requête à utiliser, l'optimiseur Jet Engine utilise des statistiques. Les facteurs suivants sont quelques-uns des facteurs sur lesquels ces statistiques sont basées:

  • Le nombre d'enregistrements dans une table
  • Le nombre de pages de données dans une table
  • L'emplacement de la table
  • Présence d'index
  • À quel point les index sont uniques

Remarque : vous ne pouvez pas afficher les schémas d'optimisation du moteur de base de données Jet et vous ne pouvez pas spécifier comment optimiser une requête. Cependant, vous pouvez utiliser Database Documenter pour déterminer si des index sont présents et à quel point un index est unique.

Sur la base de ces statistiques, l'Optimizer sélectionne ensuite la meilleure stratégie de requête interne pour traiter une requête particulière.

Les statistiques sont mises à jour chaque fois qu'une requête est compilée. Une requête est marquée pour être compilée lorsque vous enregistrez les modifications apportées à la requête (ou à ses tables sous-jacentes) et lorsque la base de données est compactée. Si une requête est marquée pour la compilation, la compilation et la mise à jour des statistiques se produisent la prochaine fois que la requête est exécutée. La compilation prend généralement entre une seconde et quatre secondes.

Si vous ajoutez un nombre important d'enregistrements à votre base de données, vous devez ouvrir, puis enregistrer vos requêtes pour recompiler les requêtes. Par exemple, si vous concevez puis testez une requête à l'aide d'un petit ensemble d'exemples de données, vous devez recompiler la requête après l'ajout d'enregistrements supplémentaires à la base de données. Lorsque vous effectuez cette opération, vous voulez vous assurer que les performances de requête optimales sont atteintes lorsque votre application est en cours d'utilisation.

Réf .

Peut être intéressant: ACC: comment optimiser les requêtes dans Microsoft Access 2.0, Microsoft Access 95 et Microsoft Access 97

Tony Toews Microsoft Access Performance FAQ vaut la peine d'être lu.

21
Mitch Wheat

Je sais que Oracle n'est pas sur votre liste, mais je pense que la plupart des bases de données modernes se comporteront de cette façon.

Vous pouvez voir dans le plan d'exécution suivant, qu'il n'y a pas de différence entre les deux instructions.

C'est un accès complet à chacune des deux tables (pas d'index dans mon cas), puis un HASH JOIN. Puisque vous voulez tout des deux tables, les deux tables doivent être lues et jointes, la séquence n'a pas d'impact.

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |   100 |   700 |    42  (12)| 00:00:01 |
|*  1 |  HASH JOIN         |      |   100 |   700 |    42  (12)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| S    |   100 |   300 |     2   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| L    |   100K|   390K|    38   (8)| 00:00:01 |
---------------------------------------------------------------------------
3
Peter Lang