Performances d'une vue ?

Bien le bonjour,

Je m'interroge sur la gestion des vues par MySQL.

Si je définis une vue comme étant le résutat d'une requête comportant un count(), l'opération count() (très couteuse) sera-t-elle exécutée à chaque lecture de la vue ? N'y a-t-il pas de mécanisme d'optimisation de MySQL (cache ou autre) permettant d'éviter de réexécuter les count() à chaque lecture ?

Merci de vos réponses.

Les vues ne sont que des requêtes nommées. Le SELECT sous-jacent à la vue s'exécute donc à chaque interrogation.

Certains SGBDR proposent des vues "matérialisées" ou "indexées. Mais comme il s'agit de techniques complexe, vous ne trouverez ce genre de chose que sur les gros SGBDR (Oracle, IBM DB2, MS SQL Server). En effet, il faut que le serveur soit capable de substituer à la volée la vue indexée en lieu et place de la requête ad-hoc, ce qui suppose des moteurs de haute volée, ce que n'est évidemment pas MySQL !

petit exemple sous MS SQL Server (vous pouvez télécharger une version d'éval avec 180 jours d'essais) :

Code:

---

1 2 3 4 5 6 7 8 9

-- création des objsts du test dans la base temporaire USE tempdb; GO   CREATE TABLE T_TEST (TST_DATE DATE, TST_VALUE INT, TST_DATA CHAR(1000)); GO

---

Code:

---

1 2 3 4 5 6

-- insertion de 100 000 lignes avec des valeurs aléatoires INSERT INTO T_TEST SELECT DATEADD(DAY, CEILING(RAND()*366), GETDATE()), RAND() * 100000, CAST(NEWID() AS VARCHAR(50)) GO 100000

---

Code:

---

1 2 3 4 5 6 7

-- création de la vue "classique" CREATE VIEW V_CLASSIQUE AS SELECT TST_DATE, SUM(TST_VALUE) AS SOMME FROM T_TEST GROUP BY TST_DATE GO

---

Code:

---

1 2 3 4

SET STATISTICS IO ON; --> demande l'affiche des statistiques de lecture GO SELECT * FROM V_CLASSIQUE

---

Table 'T_TEST'. Nombre d'analyses 5, lectures logiques 14293, lectures physiques 0...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

-- création de la vue indexable et de son index CREATE VIEW dbo.V_INDEXEE WITH SCHEMABINDING AS SELECT TST_DATE, SUM(TST_VALUE) AS SOMME, COUNT_BIG(*) AS NOMBRE FROM dbo.T_TEST GROUP BY TST_DATE GO   CREATE UNIQUE CLUSTERED INDEX X ON dbo.V_INDEXEE (TST_DATE); GO

---

Code:

---

1 2 3 4 5 6

-- test de lecture de la vue SET STATISTICS IO ON; GO   SELECT * FROM dbo.V_INDEXEE

---

Table 'V_INDEXEE'. Nombre d'analyses 1, lectures logiques 4, lectures physiques 0...

Gain obtenu : 3500 fois plus rapide.

CQFD !

Plus étonnant, faisons la même requête qu'au départ :

Code:

---

1 2 3 4

SET STATISTICS IO ON; --> demande l'affiche des statistiques de lecture GO SELECT * FROM V_CLASSIQUE

---

Table 'V_INDEXEE'. Nombre d'analyses 1, lectures logiques 4, lectures physiques 0...

Vous ne rêvez pas... la requête sur la vue classique a été transformé mathématiquement par le moteur SQL en une requête sur la vue indexée pour bénéficier de l'optimisation fournit par cette dernière.
Il s'agit en l'espèce d'un cas très simple. Mais comprenez qu'un tel effort de traduction pour des requêtes complexes soit une activité intense pour le moteur au moment de l'établissement de son plan de requête. En effet l'algo de base est exponentiel !


A +