mysql视图学习总结

转自http://www.cnblogs.com/wangtao_20/archive/2011/02/24/1964276.html

1、使用视图的理由是什么？ 1.安全性。通常是这样作的:建立一个视图，定义好该视图所操做的数据。以后将用户权限与视图绑定。这样的方式是使用到
了一个特性：grant语句能够针对视图进行授予权限。 2.查询性能提升。
3.有灵活性的功能需求后，须要改动表的结构而致使工做量比较大。那么可使用虚拟表的形式达到少修改的效果。

这是在实际开发中比较有用的

例子：假如由于某种须要，a表与b表须要进行合并起来组成一个新的表c。最后a表与b表都不会存在了。而因为原来程序中编
写sql分别是基于a表与b表查询的，这就意味着须要从新编写大量的sql(改为向c表去操做数据)。而经过视图就能够作到不修
改。定义两个视图名字仍是原来的表名a和b。a、b视图完成从c表中取出内容。
说明：使用这样的解决方式，基于对视图的细节了解越详细越好。由于使用视图仍是与使用表的语法上没区别。好比视图名a ，那么查询仍是"select * from a"。
4.复杂的查询需求。能够进行问题分解，而后将建立多个视图获取数据。将视图联合起来就能获得须要的结果了。

视图的工做机制:当调用视图的时候，才会执行视图中的sql，进行取数据操做。视图的内容没有存储，而是在视图被引用的时候才派生出数据。这样不会占用空间，因为是即时引用，视图的内容老是与真实表的内容是一致的。

视图这样设计有什么好处？节省空间，内容是老是一致的话，那么咱们不须要维护视图的内容，维护好真实表的内容，就能够保证视图的完整性了。
2、经过更新视图实现更新真实表

看到不少例子，更新视图能够更新真实表。缘由，我是这样理解的：视图并无保存内容。只是引用数据。那么，更新视图，其实就是以引用的方式操做了真实表 with check option：对视图进行更新操做的时，须要检查更新后的值是否仍是知足视图公式定义的条件。通俗点，就是所更新的结果是否还会在视图中存在。若是更新后的值不在视图范围内，就不容许更新若是建立视图的时候，没有加上with check option，更新视图中的某项数据的话，mysql并不会进行有效性检查。删掉了就删掉了。在视图中将看不到了。
使用有效性检查，实际意义是什么？
视图的实践：从新组织表的需求 CREATE TABLE `result` (`MATH_NO` INT(10) NOT NULL unsigned AUTO_INCREMENT PRIMARY KEY, `TEAMNO` INT(10) NOT NULL, `PLAYERNO` INT(10) NOT NULL, `WON` VARCHAR(10) NOT NULL, `LOST` VARCAHR(10) NOT NULL, `CAPTAIN` INT(10) NOT NULL COMMIT '就是PLAYERNO的另外名字', `DIVISION` VARCHAR(10) NOT NULL ) ENGINE=MYISAM  DEFAULT CHARSET=utf8 COMMIT='从新组的新表' AUTO_INCREMENT=1
针对每一个表建立一个视图，将数据保存进去： CREATE VIEW teams(TEAMNO,PLAYERNO,DIVISION) AS SELECT  DISTINCT TEAMNO,CAPTAIN,DIVISION FROM result
报错：#1050 - Table 'teams' already exists
说明，由于视图也是一种表，是虚拟表。不能与已有的表(视图)出现重名
接下来，删掉表teams，再执行建立视图的代码。
将视图当作与表同样的东西，更加容易理解使用规则。下面这样对比也许使本身更好理解：
1.在使用视图的时候，就是与使用表的语法同样的。 2.建立视图的时候，该视图的名字若是与已经存在表重名的话，那么会报错，不容许建立。视图就是一种特殊的表
3.建立视图的时候，能够这样使用CREATE VIEW teams(TEAMNO,PLAYERNO,DIVISION)，能够定义视图表的结构。 4.在phpmyadmin中。左边的表列表中将视图与表列在了一块儿。只有经过右侧的状态"View:teams"能够知道该表是视图表。

视图在mysql中的内部管理机制:
视图的记录都保存在information_schema数据库中的一个叫views的表中。具体某个视图的定义代码以及属于哪一个数据库等信息能够从里面看到理解视图的两种工做机制：
语句：select * from teams
针对上面语句，总结几个知识点 1.确认是视图的过程：teams也能够是表名。因为表与视图的物理机制不一样。视图自己是不存储内容的。因此，在使用sql的 时候，mysql是怎么知道teams是一个视图仍是表。是由于有一个查看目录的例程在作这件事。

2.mysql对处理视图的两种方法：替代方式和具体化方式。 替换方式理解，视图名直接使用视图的公式替换掉了。针对上面视图teams，mysql会使用该视图的公式进行替换，视图公式合并到了select中。结果就是变成了以下sql语句： select * from (SELECT  DISTINCT TEAMNO,CAPTAIN,DIVISION FROM result)。也就是最后提交给mysql处理该sql语句。
具体化方式理解，mysql先获得了视图执行的结果，该结果造成一个中间结果暂时存在内存中。以后，外面的select语句就调
用了这些中间结果(临时表)。
看起来都是要获得结果，形式上有区别，好像没体会到本质上的区别。两种方式又有什么样的不一样呢？
替换方式，将视图公式替换后，当成一个总体sql进行处理了。具体化方式，先处理视图结果，后处理外面的查询需求。 替换方式能够总结为，先准备，后执行。 具体化方式总结理解为，分开处理。
哪一种方式好？不知道。mysql会本身肯定使用哪一种方式进行处理的。本身在定义视图的时候也能够指定使用何种方式。像这样
使用：
CREATE ALGORITHM=merge VIEW teams as SELECT  DISTINCT TEAMNO,CAPTAIN,DIVISION FROM result
ALGORITHM有三个参数分别是：merge、TEMPTABLE、UNDEFINED
看mysql手册中提到，替换与具体化的方式的各自适用之处，能够这样理解： 由于临时表中的数据不可更新。因此，若是使用参数是TEMPTABLE，没法进行更新。 当你的参数定义是UNDEFINED(没有定义ALGORITHM参数)。mysql更倾向于选择合并方式。是由于它更加有效。