Comment MySQL vues travail?

Question

Quand je crée une vue que je fais essentiellement une nouvelle table qui sera automatiquement traitée sur lorsque les données d'une des tables qu'il réunit des changements; est-ce exact?

Aussi pourquoi je ne peux pas utiliser les sous-requêtes à mon avis?

Answer 1

Une vue des œuvres comme une table , mais ce n'est pas une table. Il existe jamais; il est seulement une instruction SQL préparée qui est exécutée lorsque vous faites référence au nom de la vue. IE:

CREATE VIEW foo AS
  SELECT * FROM bar

SELECT * FROM foo

... est équivalent à l'exécution:

SELECT x.* 
  FROM (SELECT * FROM bar) x

Un mysqldump ne sera jamais contenir des lignes à insérer dans une vue ...

  

Aussi pourquoi je ne peux pas utiliser les sous-requêtes à mon avis ????

Ce, est malheureusement par (quoique discutable) la conception. Il y a de nombreuses limites pour MySQL vues, qui sont documentées: http: // dev.mysql.com/doc/refman/5.0/en/create-view.html

Donc, si c'est juste une table imaginaire / déclaration préparée que cela veut dire qu'il a théoriquement les mêmes performances (ou encore moins) comme une table normale / requête?

---

Non.
Une table peut avoir des indices associés, ce qui peut rendre la récupération des données plus rapidement (à un coût pour une insertion / mise à jour). Certaines bases de données prennent en charge « matérialisée » vues, qui sont des vues qui peuvent avoir des indices pour les appliquer - qui ne devrait pas être une surprise que MySQL ne supporte pas compte tenu de la fonctionnalité limitée (qui n'a commencé à v5 IIRC, très tard dans le jeu).

Parce qu'une vue est une table dérivée, la performance de la vue est aussi bonne que la requête est construit sur. Si cette requête est nul, la question de la performance sera juste boule de neige ... Cela dit, lors de l'interrogation d'une vue - si une référence de colonne de vue dans la clause WHERE n'est pas enveloppé dans une fonction (IE: WHERE v.column LIKE ..., pas WHERE LOWER(t.column) LIKE ...), l'optimiseur peut pousser les critères (appelé un prédicat) sur la requête initiale - ce qui rend plus rapide

.

Answer 2

je suis tombé sur le même problème aussi (à ma grande surprise, parce que ma recherche semble indiquer que Oracle et MS ne le supportent).

Je reçois cette limitation (au moins pour l'instant, jusqu'à ce que non utilisable éprouvée) en créant deux vues supplémentaires pour mon avis final.

Exemple:

CREATE VIEW Foo1 AS
    SELECT * FROM t ORDER BY ID, InsertDate DESC

CREATE VIEW Foo2 AS
    SELECT * FROM Foo1 GROUP BY ID

CREATE VIEW Foo AS
    SELECT * FROM Foo2 ORDER BY ID

L'exemple ci-dessus a essentiellement une table « t » qui est une table temporelle contenant toutes les révisions. Ma (vue) « Foo » est essentiellement une simple vue de seulement mes plus révisions de chaque enregistrement. Semble bien du travail pour l'instant!

Mise à jour:

Je ne sais pas si cela est un autre bogue dans MySQL 5.1, mais l'exemple ci-dessus ne fonctionne pas dans le travail de fait! Les travaux « foo1 » comme prévu, mais le « foo2 » semble ignorer l'ordre avant le regroupement donc mon résultat final n'est pas ce qui est prévu. Je reçois même le même résultat si je change le « DESC » pour « ASC » (étonnamment).

En outre, si vous lisez le 17.5.1. Voir Syntaxe , elle indique clairement:

  

« Une vue peut être créé à partir de nombreux types d'instructions SELECT. Il peut se référer aux tables de base ou d'autres vues. Il peut avoir recours aux jointures, UNION, et les sous-requêtes. »

Je vais mettre à jour ma base de données à 5.6 et essayer à nouveau!

Answer 3

La différence est la suivante:

pour une vue vous ne pouvez avoir dans le sous-requêtes où - une partie, pas dans le de - part donc un

CREATE VIEW v AS SELECT * FROM foo WHERE id IN (SELECT id FROM bar) 

travaillerait - mais en même temps vous obtenez une vue en lecture seule ... Une vue simple sur une seule table permettrait de mettre à jour « par » en vue de la table sous-jacente