Ce qui répondrait à votre question est le sujet JOIN DECOMPOSITION.
Selon la page 209 du livre
Vous pouvez décomposer une jointure en exécutant plusieurs requêtes à table unique au lieu d'une jointure multitable, puis en effectuant la jointure dans l'application. Par exemple, au lieu de cette requête unique:
SELECT * FROM tag
JOIN tag_post ON tag_post.tag_id = tag.id
JOIN post ON tag_post.post_id = post.id
WHERE tag.tag = 'mysql';
Vous pourriez exécuter ces requêtes:
SELECT * FROM tag WHERE tag = 'mysql';
SELECT * FROM tag_post WHERE tag_id=1234;
SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);
Pourquoi diable ferais-tu cela? Cela semble inutile à première vue, car vous avez augmenté le nombre de requêtes sans rien obtenir en retour. Cependant, une telle restructuration peut en réalité offrir des avantages significatifs en termes de performances:
- La mise en cache peut être plus efficace. De nombreuses applications mettent en cache des "objets" mappés directement sur des tables. Dans cet exemple, si l'objet avec la balise
mysqlest déjà mis en cache, l'application ignorera la première requête. Si vous trouvez des publications avec un identifiant de 123, 567 ou 908 dans le cache, vous pouvez les supprimer de la IN()liste. Le cache de requêtes pourrait également bénéficier de cette stratégie. Si une seule des tables change fréquemment, la décomposition d'une jointure peut réduire le nombre d'invalidations du cache.
- L'exécution individuelle des requêtes peut parfois réduire les conflits de verrous
- Les jointures dans l'application facilitent la mise à l'échelle de la base de données en plaçant des tables sur différents serveurs.
- Les requêtes elles-mêmes peuvent être plus efficaces. Dans cet exemple, utiliser une
IN()liste au lieu d'une jointure permet à MySQL de trier les ID de ligne et de récupérer les lignes de manière plus optimale qu'avec une jointure.
- Vous pouvez réduire les accès redondants aux lignes. Faire une jointure dans l'application signifie extraire chaque ligne une seule fois, alors qu'une jointure dans la requête est essentiellement une dénormalisation qui peut accéder de manière répétée aux mêmes données. Pour la même raison, une telle restructuration pourrait également réduire le trafic total sur le réseau et l'utilisation de la mémoire.
- Dans une certaine mesure, vous pouvez voir cette technique comme implémentant manuellement une jointure de hachage au lieu de l'algorithme de boucles imbriquées utilisé par MySQL pour exécuter une jointure. Une jointure de hachage pourrait être plus efficace.
En conséquence, les jointures des actions dans l'application peuvent être plus efficaces lorsque vous mettez en cache et réutilisez une grande quantité de données de requêtes précédentes, que vous répartissez les données sur plusieurs serveurs, que vous remplacez les jointures par des IN()listes ou que la jointure fait référence à la même table plusieurs fois.
OBSERVATION
J'aime le premier point parce qu'InnoDB est un peu lourd lorsqu'il vérifie le cache de requêtes.
En ce qui concerne le dernier point, j'ai écrit un article le 11 mars 2013 ( Existe-t-il une différence d'exécution entre une condition JOIN et une condition WHERE? ) Décrivant l'algorithme de la boucle imbriquée. Après l'avoir lu, vous verrez à quel point la décomposition des jointures est efficace.
Comme pour tous les autres points du livre , les développeurs recherchent vraiment la performance comme résultat. Certaines s'appuient sur des moyens externes (en dehors de l'application) pour améliorer les performances, telles que l'utilisation d'un disque rapide, l'obtention de davantage de processeurs / cœurs, le réglage du moteur de stockage et le fichier de configuration. D'autres vont s'attacher et écrire un meilleur code. Certains peuvent recourir à la codification de toute l'intelligence d'affaires dans les procédures stockées, sans toujours appliquer la décomposition de jointure (voir Quels sont les arguments contre ou pour placer la logique d'application dans la couche base de données? Avec les autres publications). Tout dépend de la culture et de la tolérance de chaque développeur.
Certains peuvent être satisfaits des performances et ne plus toucher au code. D’autres ne réalisent tout simplement pas qu’il ya de grands avantages à tirer s’ils essaient de joindre la composition.
Pour les développeurs qui veulent ...
ESSAIE !!!