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

Cela peut être une question stupide, mais il peut jeter une certaine lumière sur la façon dont les jointures de travail à l'interne.

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

Y aurait-il une différence en termes 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;

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

Je me rends compte de la performance peut varier entre les différentes SQL langues. Si oui, comment MySQL comparer à l'Accès?

InformationsquelleAutor Zaid | 2010-02-13
  1. 19

    Non, l'ordre n'a pas d'importance.

    Presque tous du SGBDR (par exemple MS Access, MySQL, SQL Server, ORACLE, etc) utiliser un coût en fonction de l'optimiseur basé sur les statistiques de colonne. Dans la plupart des situations, l'optimiseur va choisir un bon plan. Dans l'exemple que vous avez donné, l'ordre n'a pas d'importance (à condition que les statistiques sont à jour).

    De décider quelle stratégie de requête à utiliser,
    le Moteur Jet optimiseur utilise
    les statistiques. Les facteurs suivants sont
    certains des facteurs que ces
    les statistiques sont basées sur:

    • Le nombre d'enregistrements dans une table
    • Le nombre de pages de données dans une table
    • L'emplacement de la table
    • Si les index sont présents
    • Les index uniques sont

    Note: Vous ne pouvez pas afficher de base de données Jet d'optimisation de moteur de régimes, et vous
    ne peut pas spécifier comment optimiser une
    de la requête. Toutefois, vous pouvez utiliser le
    Documentation de base de données pour déterminer
    si les index sont présents et
    un index uniques est.

    Sur la base de ces statistiques, le
    L'optimiseur choisit alors le meilleur
    requête interne de la stratégie de traitement
    avec une requête particulière.

    Les statistiques sont mises à jour chaque fois qu'un
    la requête est compilé. Une requête est signalée
    pour la compilation lorsque vous enregistrez des
    modifications apportées à la requête (ou de ses
    les tables sous-jacentes) et lors de la
    la base de données est compactée. Si une requête est
    marqué pour l'élaboration, la compilation
    et la mise à jour des statistiques se produit
    la prochaine fois que la requête est exécutée.
    Compilation généralement prend une
    deuxième à quatre secondes.

    Si vous ajoutez un nombre important de
    les enregistrements de votre base de données, vous devez
    ouvrez et enregistrez vos requêtes pour
    recompiler les requêtes. Par exemple, si
    vous concevez et ensuite de tester une requête par
    à l'aide d'un petit ensemble de données de l'échantillon, vous
    doit re-compiler la requête après
    documents supplémentaires sont ajoutés à la
    la base de données. Lorsque vous faites cela, vous voulez
    assurez-vous que la requête optimal
    les performances sont obtenues lorsque votre
    l'application est en cours d'utilisation.

    Ref.

    Pourrait être d'intérêt: ACC: Comment faire pour Optimiser les Requêtes dans Microsoft Access 2.0, Microsoft Access 95 et Microsoft Access 97

    Tony Toews est Microsoft Access Performance FAQ vaut la peine de lire.

    • Donc, étant donné que les deux tables ont des index uniques, les performances peuvent varier au cas par cas?
    • si les stats sont à jour (et de la requête est recompilé comme indiqué ci-dessus), puis de l'ordre de la jointure n'a pas d'importance; l'optimiseur de choisir le droit chemin.
    InformationsquelleAutor Mitch Wheat
  2. 2

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

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

    C'est un accès complet à chacune des deux tables (pas d'index dans mon cas), et puis un HASH JOIN. Puisque vous voulez tout de deux tables, deux tables doivent être lues et a rejoint, 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 |
---------------------------------------------------------------------------
    InformationsquelleAutor Peter Lang