Les vues MySQL peuvent-elles tirer parti des améliorations de l'index pour améliorer les performances ?

L'utilisation des vues MySQL est-elle une pratique préjudiciable ?

Malgré les conseils suggérant le contraire, les vues peuvent en effet tirer parti des améliorations de l'index lorsqu'elles sont utilisées dans MySQL . La question se pose de savoir comment une telle fonctionnalité peut être implémentée.

La réponse : fournir des index appropriés

La solution réside dans l'offre d'un index que MySQL peut utiliser activement. Dans ce cas, un index « de couverture » est le plus approprié, tel que :

CREATE INDEX highscores_IX3 ON highscores (player, happened_in, score)

Avec cet index en place, l'optimiseur de MySQL devrait pouvoir l'utiliser pour la requête SELECT, ce qui entraînera un message « Utilisation de l'index " déclaration attribuable au prédicat WHERE player = 24.

Cependant, il est essentiel de reconnaître qu'il est peu probable que MySQL utilise un index arriva_in pour les requêtes de vue en raison de son comportement consistant à séparer les exécutions internes de « requêtes de vue » des requêtes externes. Par conséquent, l'index défini pour arriva_in ne sera pas utilisé pendant la phase de formation de la requête.

Optimisation des performances avec un index de couverture

Pour optimiser les performances des requêtes de vue, un "couvrant index" qui inclut toutes les colonnes référencées dans la requête (par exemple, ON highscores (player, wanted_in, score)) est recommandé. Ce type d'index permet une récupération directe des données à partir des pages d'index sans avoir besoin de recherches de pages dans la table sous-jacente, ce qui entraîne une méthode d'accès « Utilisation de l'index ».

Comparaison avec une requête autonome sans table dérivée

À titre de comparaison, considérons une requête autonome équivalente à la requête de vue :

SELECT player, MAX(score) AS highest_score, happened_in
FROM highscores
WHERE player = 24 AND happened_in = 2006
GROUP BY player, happened_in

Une couverture l'index pour cette requête (par exemple, ON highscores (player, wanted_in, score)) peut également être utilisé, éliminant ainsi le besoin d'une table intermédiaire « dérivée ».

Attention et considérations

Bien que les vues ne soient pas intrinsèquement préjudiciables, il est crucial de comprendre comment les processus MySQL visualisent les requêtes, ce qui diffère des approches adoptées par d'autres bases de données. Ces connaissances permettent aux développeurs d'exploiter efficacement le potentiel des vues tout en atténuant les pièges en matière de performances.

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!