Discussion :

[khayyam90]

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.

[SQLpro]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 +