Pourquoi l'utilisation de tables temporaires avec une instruction SELECT améliore-t-elle le nombre d'E/S logiques? Cela n'augmenterait-il pas la quantité de résultats dans une base de données au lieu de la diminuer. Est-ce parce que le «problème» est divisé en sections? J'aimerais savoir ce qui se passe dans les coulisses.Tables temporaires et performances SQL SELECT
Il n'y a pas de réponse générale. Cela dépend de la façon dont la table temporaire est utilisée.
La table temporaire peut réduire les E/S en mettant en cache les lignes créées après un filtre/une jointure complexe qui sont utilisés plusieurs fois plus tard dans le lot. De cette façon, la base de données peut éviter de toucher plusieurs fois les tables de base lorsque seul un sous-ensemble des enregistrements est nécessaire. La table temporaire peut augmenter IO en stockant des enregistrements qui ne sont jamais utilisés plus tard dans la requête, ou en prenant beaucoup d'espace dans le cache du moteur qui aurait pu être mieux utilisé par d'autres données. La création d'une table temporaire pour utiliser tout son contenu une fois est plus lente que l'inclusion de la requête temporaire dans la requête principale, car l'optimiseur de requête ne peut pas voir la table temporaire et force spool (probablement) inutile au lieu de lui permettre de diffuser à partir des tables source.
il vaut la peine de mentionner que normalement une table temporaire est construite en tant que type MEMORY seulement si votre RAM ou votre config ne permettent pas une telle table d'enregistrement de gib son utilisation du disque, ce qui ralentit les tables temporaires. – Rufinus
AFAIK, au moins avec MySQL, tables tmp sont conservés dans la mémoire vive, ce qui rend SELECTs beaucoup plus vite que tout ce qui touche le HD
Il y a une classe de problèmes où la construction du résultat dans une structure de collecte du côté de la base de données est beaucoup préférable de retourner les parties du résultat au client, aller-retour pour chaque partie.
Par exemple: relations récursives de profondeur arbitraire (patron de)
Il y a une autre classe de problèmes de requête où les données ne sont pas et ne sera pas indexé d'une manière qui rend la requête exécutée de manière efficace. Extraire les résultats dans une structure de collection, qui peut être indexée de manière personnalisée, réduira les E/S logiques pour ces requêtes.
Je vais supposer par les tables temporaires que vous voulez dire un sous-select dans une clause WHERE. (Cette opération est appelée une opération semijoin et vous pouvez généralement la voir dans le plan d'exécution de texte pour votre requête.)
Lorsque l'optimiseur de requête rencontre une table de sous-sélection/temporaire, il fait des suppositions sur ce qu'il doit faire avec ces données. Essentiellement, l'optimiseur crée un plan d'exécution qui effectue une jointure sur l'ensemble de résultats du sous-sélection, réduisant ainsi le nombre de lignes à lire dans les autres tables. Comme il y a moins de lignes, le moteur de recherche peut lire moins de pages à partir du disque/de la mémoire et réduire la quantité d'E/S requise.
Quel SGBD? De quel SQL parlez-vous - collez-le! –