MYSQL 视图

表和视图共享数据库中相同的名称空间，因此，数据库不能包含具有相同名称的表和视图。

视图定义服从下述限制：

· SELECT 语句不能包含FROM 子句中的子查询。[select qty from (select * from t) as c order by qty desc] 允许查询不允许用来作为视图

· SELECT 语句不能引用 系统或用户变量。

· SELECT 语句不能 引用预处理语句参数。

· 在存储子程序内，定义不能引用子程序参数或局部变量。

· 在定义中引用的表或视图必须存在。但是，创建了视图后，能够舍弃定义引用的表或视图。要想检查视图定义是否存在这类问题，可使用CHECK TABLE 语句。

· 在定义中不能引用TEMPORARY 表， 不能创建TEMPORARY 视图 。

· 在视图定义中命名的表必须已存在。

· 不能将触发程序与视图关联在一起。

算法会影响MySQL 处理视图的方式。

对于MERGE ，会 将引用视图的语句的文本与视图定义合并起来，使得视图定义的某一部分取代语句的对应部分。

对于TEMPTABLE ，视图的结果将被置于临时表中，然后使用它执行语句。

对于UNDEFINED ， MySQL 将选择所要使用的算法。如果可能，它倾向于MERGE 而不是 TEMPTABL E ，这是因为MERGE 通常更有效，而且如果使用了临时表，视图是不可更新的。

明确选择 TEMPTABLE 的1 个原因在于 ，创建临时表之后、并在完成语句处理之前，能够释放基表上的锁定。与MERGE 算法相比，锁定释放的速度更快，这样，使用视图的其他客户端不会被屏蔽过长时间。

MERGE 算法 要求视图中的行和基表中的行具有一对一的关系 。如果不具有该关系。必须使用临时表取而代之 。如果视图包含下述结构中的任何一种，将失去 一对一的关系：

· 聚合函数（SUM() , MIN() , MAX() , COUNT() 等）。

· DISTINCT

· GROUP BY

· HAVING

· UNION 或UNION ALL

· 仅引用文字值（在该情况下，没有基本表）。

某些视图是可更新的。也就是说，可以在诸如UPDATE 、DELETE 或INSERT 等语句中使用它们，以更新基表的内容。对于可更新的视图 通过视图修改基本表数据 ，在视图中的行和基表中的行之间必须具有一对一的关系 [视图列和基表列斯对应关系co1,co2，如果试图列是通过通过类似(co1*co2) as co3的方式产生的是不可更新的，也就是说co1和co2可更新，co3不可更新] 。还有一些特定的其他结构，这类结构会使得视图不可更新。更具体地讲，如果视图包含下述结构中的任何一种，那么它就是不可更新的：

· 聚合函数（SUM() , MIN() , MAX() , COUNT() 等）。

· DISTINCT

· GROUP BY

· HAVING

· UNION 或UNION ALL

· 位于选择列表中的子查询

· Join

· FROM 子句中的不可更新视图

· WHERE 子句中的子查询，引用FROM 子句中的表。

· 仅引用文字值（在该情况下，没有要更新的基本表）。

· ALGORITHM = TEMPTABLE （使用临时表总会使视图成为不可更新的） 。

关于可插入性（可用INSERT 语句更新） ，如果它也满足关于视图列的下述额外要求，可更新的视图也是可插入的：

· 不得有重复的视图列名称。

· 视图必须包含没有默认值的基表中的所有列。

· 视图列必须是简单的列引用而不是导出列 。导出列不是简单的列引用，而是从表达式导出的。下面给出了一些导出列示例：

· 

3.14159

· 

col1 + 3

· 

UPPER(col2)

· 

col3 / col4

· 

(subquery

) 子查询

混合了简单列引用和导出列的视图是不可插入的，但是，如果仅更新非导出列，视图是可更新的。考虑下述视图：

CREATE VIEW v AS SELECT col1, 1 AS col2 FROM t;

该视图是不可插入的，这是因为col2 是从表达式导出的。但是，如果更新时不更新col2 ，它是可更新的。这类更新是允许的：

UPDATE v SET col1 = 0;

下述更新是不允许的，原因在于，它试图更新导出列：

UPDATE v SET col2 = 0;

在某些情况下，能够更新多表视图，假定它能使用MERGE 算法进行处理。为此，视图必须使用内部联合（而不是外部联合或 UNION 有待验证 ）。 此外，仅能更新视图定义中的单个表，因此，SET 子句必须仅命名视图中某一表的列。即使从理论上讲也是可更新的，不允许使用UNION ALL 的视图，这是因为，在实施中将使用临时表 来处理它们 。

对于多表可更新视图，如果是将其插入单个表中，INSERT 能够工作。 不支持DELETE 。

对于可更新视图，可给定WITH CHECK OPTION 子句来防止插入或更新行，除非作用在行上的select_statement 中的WHERE 子句为“真”。

在关于可更新视图的WITH CHECK OPTION 子句中，当视图是根据另一个视图定义的时，LOCAL 和CASCADED 关键字 决定了检查测试的范围。LOCAL 关键字对CHECK OPTION 进行了限制，使其仅作用在定义的视图上，CASCADED 会对将进行评估的基表进行检查。如果未给定任一关键字，默认值为CASCADED 。 请考虑下述表和视图集合的定义：

mysql> CREATE TABLE t1 (a INT);

mysql> CREATE VIEW v1 AS SELECT * FROM t1 WHERE a < 2

 -> WITH CHECK OPTION;

mysql> CREATE VIEW v2 AS SELECT * FROM v1 WHERE a > 0

 -> WITH LOCAL CHECK OPTION;

mysql> CREATE VIEW v3 AS SELECT * FROM v1 WHERE a > 0

 -> WITH CASCADED CHECK OPTION;

这里，视图v2 和v3 是根据另一视图v1 定义的 。v2 具有LOCAL 检查选项，因此，仅会针对v2 检查对插入项进行测试。v3 具有CASCADED 检查选项，因此，不仅会针对它自己的检查对插入项进行测试， 也会针对基本视图的检查对插入项进行测试 。在下面的语句中，介绍了这些差异：

ql> INSERT INTO v2 VALUES (2);

Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO v3 VALUES (2);

ERROR 1369 (HY000): CHECK OPTION failed 'test.v3'

视图的可更新性可能会受到系统变量updatable_views_with_limit 的值的影响。 请参见5.3.3节，“服务器系统变量” 。

INFORMATION_SCHEMA 包含1 个VIEWS 表，从该表可获取关于视图对象的信息 。请参见23.1.15节，“INFORMATION_SCHEMA VIEWS表” 。