Que sont la requête de jointure de MySQL et les méthodes de requête multiples ?

Comparaison entre la requête de jointure et les requêtes multiples

La requête MySQL liée à plusieurs tables est-elle plus efficace ou les requêtes multiples à table unique ?

Lorsque la quantité de données n'est pas assez grande, il n'y a aucun problème à utiliser la jointure, mais cela se fait généralement sur la couche de service

Premièrement : les ressources informatiques de la base de données autonome sont très coûteuses et la base de données doit servir à la fois l'écriture et la lecture, ce qui nécessite une consommation de processeur. Afin d'augmenter le débit de la base de données, et que l'entreprise ne se soucie pas de l'écart de retard de plusieurs centaines de microsecondes à millisecondes, l'entreprise effectuera davantage de calculs. couche de service. Après tout, les ressources informatiques peuvent être facilement étendues horizontalement et les bases de données sont difficiles à exploiter. La plupart des entreprises placeront donc des opérations informatiques pures sur la couche de service et utiliseront la base de données comme un système kv avec des capacités de transaction. idée qui met l'accent sur les bases de données commerciales et légères

Deuxième : de nombreuses entreprises complexes ne peuvent pas utiliser une seule base de données pour des raisons de développement historique. Généralement, une couche de middleware sera ajoutée à plusieurs bases de données. Il n'y aura aucun moyen de joindre plusieurs bases de données. Naturellement, l'entreprise en fera abstraction. La couche de service réduit le couplage à la base de données.

Troisièmement : Pour certaines grandes entreprises, en raison de la grande échelle des données, elles doivent créer des sous-bases de données et des sous-tables. Pour l'application de sous-bases de données et de sous-tables, l'utilisation de la jointure est également soumise à de nombreuses restrictions. , à moins que l'entreprise ne puisse définir clairement les exigences basées sur la clé de partitionnement. Les deux tables jointes se trouvent dans la même base de données physique. Le middleware ne prend généralement pas bien en charge les jointures entre bases de données.

Pour donner un exemple commercial très courant, dans une sous-base de données et une sous-table, deux tables doivent être mises à jour de manière synchrone. Les deux tables sont situées dans des bibliothèques physiques différentes. Afin de garantir la cohérence des données, une approche consiste à utiliser. une transaction distribuée intermédiaire Le logiciel met deux opérations de mise à jour en une seule transaction, mais ces opérations nécessitent généralement un verrouillage global, ce qui entraîne de mauvaises performances. Cependant, certaines entreprises peuvent tolérer des incohérences de données à court terme. Laissez-les être mis à jour séparément, mais il y aura un problème d'échec d'écriture des données. Ensuite, démarrez une tâche planifiée, analysez la table A pour les lignes ayant échoué, puis voyez si la table B est également écrite avec succès, puis associez ces deux associations lors de la révision. enregistrements, il est également impossible d'utiliser join pour l'implémenter. Les données ne peuvent être extraites que vers la couche de service et l'application elle-même les fusionne. . .

En fait, reconstruire les requêtes en décomposant les requêtes associées présente les avantages suivants :

Rendre la mise en cache plus efficace.

De nombreuses applications peuvent facilement mettre en cache les objets de résultat correspondant aux requêtes à table unique. De plus, pour le cache de requêtes MySQL, si une table dans l'association change, le cache de requêtes ne peut pas être utilisé. Après le fractionnement, si une table change rarement, les requêtes basées sur la table peuvent être répétées.

Après avoir décomposé la requête, l'exécution d'une seule requête peut réduire les conflits de verrouillage.

L'association au niveau de la couche application facilite le fractionnement de la base de données et permet d'obtenir des performances et une évolutivité élevées.

L'efficacité de la requête elle-même peut également être améliorée

La requête des enregistrements redondants peut être réduite.

Pour aller plus loin, cela équivaut à implémenter une association de hachage dans l'application, au lieu d'utiliser l'association d'anneaux imbriqués de MySQL. Dans certains scénarios, l'association de hachage est beaucoup plus efficace.

Ordre d'exécution des instructions de requête join, on,where

Ordre d'exécution MySQL

1. Ordre d'exécution complet d'une instruction SELECT typique

1) La clause from assemble des données provenant de différentes sources de données

2) Utilisez on pour effectuer ; Filtrage des données pour les connexions de jointure

3) où la clause filtre les lignes d'enregistrement en fonction de conditions spécifiées ;

4) la clause group by divise les données en plusieurs groupes

5) cube, cumul

6) utiliser les fonctions d'agrégation pour les calculs ; ;

7) Utilisez la clause have pour filtrer les regroupements ;

8) Calculez toutes les expressions ;

9) Calculez les champs sélectionnés

10) Utilisez distinct pour dédupliquer les données

11) Utilisez l'ordre par tri pour l'ensemble de résultats ;

12) Sélectionnez les données TOPN

2. from

Si l'association de la tableA, la tableB est utilisée, ces deux tables seront d'abord organisées pour le produit cartésien, puis effectueront les opérations suivantes telles que où et regrouper par.

3. on

Si vous utilisez la jointure gauche, la jointure interne ou la jointure complète externe, utilisez on pour filtrer les conditions, puis rejoignez.

Regardez les 2 sql et les résultats ci-dessous. La différence entre les deux réside dans la position après les instructions on et Where. Utilisez d’abord on pour le filtrage conditionnel, puis effectuez une opération de jointure, puis appliquez le filtrage conditionnel à l’emplacement souhaité.

Utilisez join pour vous connecter d'abord, puis utilisez on pour filtrer, ce qui formera un produit cartésien. Il n'y a aucune différence entre une telle jointure gauche et une jointure directe. Vous devez donc d’abord filtrer sur les conditions puis adhérer.

Si vous effectuez une opération JOIN après WHERE et au-dessus de ON, les résultats des deux requêtes SQL suivantes devraient être les mêmes. On peut voir où est le filtrage de l'ensemble après la jointure.

En résumé : effectuez d'abord un filtrage par condition, puis rejoignez-nous, et enfin effectuez un filtrage où

SELECT DISTINCT a.domain , b.domain
FROM mal_nxdomains_raw a
LEFT JOIN mal_nxdomains_detail b ON a.domain = b.domain AND b.date = ‘20160403'
WHERE a.date = ‘20160403'

SELECT DISTINCT a.domain , b.domain
FROM mal_nxdomains_raw a
LEFT JOIN mal_nxdomains_detail b ON a.domain = b.domain #and b.date = ‘20160403'
WHERE a.date = ‘20160403'
AND b.date = ‘20160403'

四、on 条件与where 条件

1、使用位置

• on 条件位置在join后面

• where 条件在join 与on完成的后面

2、使用对象

• on 的使用对象是被关联表

• where的使用对象可以是主表，也可以是关联表

3、选择与使用

主表条件筛选：只能在where后面使用。

被关联表，如果是想缩小join范围，可以放置到on后面。如果是关联后再查询，可以放置到where 后面。

如果left join 中，where条件有对被关联表的 关联字段的 非空查询，与使用inner join的效果后，在进行where 筛选的效果是一样的。不能起到left join的作用。

五、join 流程

在表A和表B的联接中，从A表中选出一条记录，并将其传递到B表进行扫描和匹配。所以A的行数决定查询次数，B表的行数决定扫描范围。需要运行100次从A表中取出一条数据，然后进行200次比对，将结果存储到B表中。

相对来说从A表取数据消耗的资源比较多。所以尽量tableA选择比较小的表。同时缩小B表的查询范围。

但是实际应用中，因为二者返回的数据结果不同，使用的索引也不同，导致条件放置在on 和 where 效率是不一定谁更好。要根据需求来确定。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!