什么是视图？
视图是基于 SQL 语句的结果集的可视化的表。
当然视图也是数据库中对象之一，其它的对象包括：表，数据字典，约束,索引，触发器，存储过程，以及存储函数。这些后面再聊，本篇主要聊的就是视图。
而视图本身不存储数据，而是通过映射原表，方便用户对数据进行查看和操作。
视图让用户使用表或者多个表的一部分数据，而不是所有的表数据。这样可以针对不同的用户定制不同的查询视图，这样让同样的数据对不同的人呈现不同的假表数据，其实保证了数据的安全。
视图时一种虚拟表，本身是不具有数据，占用很少的内存空间，是SQL中的重要对象。
视图的存在依托于已有的表，而这些表时基表。
视图简易理解位存储起来的SELECT语言查询结果。视图本身不存储数据的，还是前面说的时映射的数据。其实视图时向用户提供基表数据的另一种形式，通常情况下小型项目的数据库可以不适用视图。所以再大型项目，以及数据表比较复杂的情况下，视图就体现出有点了。将经常查询的记过放在视图中，提升使用效率，
其实视图本质：就是将一个表或多个表关联的查询的结果生成一个视图。而视图本身不存储数据，而是通过映射基表，方便用户对数据进行查看和操作。视图创建和删除不影响基表，但增删改会影响基表。
创建视图的格式：
CREATE [OR REPLACE ]
[ALGORITHM ={ UNDEFINED |MERGE | TEMPTABLE }]
VIEW 视图名 [(字段名)]
AS 查询语句
[WITH [CASCADED |LOCAL] CHECK OPTION ]
-- 上面时完整的结构，但是一般使用格式如下，有点像是通过数据创建表的样式。
CREATE [OR REPLACE ]
VIEW 视图名 [(字段名)]
AS 查询语句
对有些新的关键子进行讲解
现在开始演示，这个时候就用之前聊查询语言的是表进行，演示也就是，三张表：员工表，部门表和工资等级表。
员工表：
部门表：
工资等级表：
为了方便演示，直接通过员工表和部门表进行演示。
SELECT dept.dname,emp.empno,emp.ename FROM emp, dept WHERE emp.deptno=dept.deptno;
然后创建视图：
CREATE VIEW table_v AS SELECT dept.dname,emp.empno,emp.ename,emp.sal FROM emp, dept WHERE emp.deptno=dept.deptno;
-- 然后查询视图
SELECT * FROM table_v;
这个视图没有写视图的字段，这个是可以重新写字段名，但是有一点 ，就是字段个数和SELECT中的字段个数要一样。
现在有一个一个问题，前面说是的映射的表，那么带有函数的查询语句可以创建视图吗？
SELECT dept.dname,AVG(emp.sal) FROM emp, dept WHERE emp.deptno=dept.deptno GROUP BY emp.deptno
然后创建视图：
CREATE VIEW table_v1 (dname,ave_sal) AS SELECT dept.dname,AVG(emp.sal) FROM emp, dept WHERE emp.deptno=dept.deptno GROUP BY emp.deptno;
SELECT * FROM table_v1;
可以看出调用的MYSQL的函数也是可以创建视图的。如何证明是映射，后面可以通过更新基表，看其是否改变即可。后面修改后面会演示，暂时保留。
查询数据库中有多少视图：
SHOW TABLES;
查看视图结果：
DESC / DESCRIBE 视图名
例子：
DESC table_v1;
查看视图的属性信息
-- 查看视图信息（显示存储引擎，版本，数据行数和数据大小等）
SHOW TABLE STATUS LIKE '视图名';
演示例子
-- 先查询表的属性
SHOW TABLE STATUS LIKE 'emp';
SHOW TABLE STATUS LIKE 'table_v1';
通过视图和表的对比可以看出，视图中的所有属性都是NULL，所以可以通过这个命令确立要查询的表是虚拟表还是真表。
这个截图看着有点长，如果方便看可以在dos创建查看：
SHOW TABLE STATUS LIKE 'table_v1' \G
还有一个可以看创建视图的语句。
SHOW CREATE VIEW 视图名称;
-- 这个就不在演示了，毕竟前面在表中演示过。
还有可以通过视图生成视图，就像是套娃了，这个就不在演示了。
前面说过如果对数据库视图进行增删改操作会影响原来的数据库。
当然如果对基表进行操作也会影响视图，两者彼此会影响的。
现在更新一下视图的
-- 可以看出更新视图中 empno='7900'的工资950更改位1000
UPDATE table_v SET table_v.sal='1000' WHERE table_v.empno='7900';
现在看一下员工表
SELECT * FROM emp WHERE emp.empno='7900';
前面不是演示了上面没有更新的视图table_v1如下
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EKOWnpku-1643175420470)(F:\文档\笔记\数据库\mysql\12：视图.assets\image-20220123204753145.png)]
现在看一下 更新视图中 empno='7900'的工资950更改位1000,影响了基表，然后看一下基表会不会影响视图table_v1；
这个又涉及到一个神奇的操作，那就是是否可以操作table_v1中的ave_sal的值？
UPDATE table_v1 SET table_v1.ave_sal='1000' WHERE table_v1.dname='SALES';
这个可以看出视图中的字段如果在基表中没有，就会报错，这种没有不是说字段名不一样而是其来源直接没有，这个是通过计算得到的。
现在看是否删除会相互影响：
-- 通过删除视图中 empno='7900'的数据
DELETE FROM table_v WHERE empno='7900';
前面说过是UPDATE,这个相对限制很小，几乎所有的都可以操作，但是对于INSERT 和DELETE 就有点不同，这个限制有点多。
如果INSERT 和DELETE可以用前提是视图中行和底层基表中的行必须存在一对一的关系。然后看一下不能增删的视图条件：
上面总结其实有点绕，下面依次演示。
为了演示效果，所以只是简单的演示，所以数据本身就没有多少意义。
CREATE TABLE test_a(
t_id INT,
t_name VARCHAR(5),
t_flag INT
);
CREATE TABLE test_b(
t_flag INT,
t_flag_name VARCHAR(10)
);
INSERT INTO test_a VALUES (1,'a_a','1');
INSERT INTO test_a VALUES (2,'a_b','2');
INSERT INTO test_a VALUES (3,'a_c','2');
INSERT INTO test_a VALUES (4,'a_d','3');
INSERT INTO test_b VALUES (1,'b_a');
INSERT INTO test_b VALUES (2,'b_b');
INSERT INTO test_b VALUES (3,'b_c');
CREATE VIEW t_v1 AS
SELECT t_name, t_flag_name FROM test_a,test_b WHERE test_a.`t_flag`=test_b.`t_flag`;
其实UPDATE就不在演示了，毕竟前面已经演示了，现在看是否可以插入和删除。
首先插入：
INSERT INTO t_v1 VALUES ('a_g','b_g');
提示前面没有知名后面的数据指定的字段名，所以这个可以补充字段才行，前提可以试一下如果只有一个字段呢？
CREATE VIEW t_v2 AS
SELECT t_name FROM test_a,test_b WHERE test_a.`t_flag`=test_b.`t_flag`;
INSERT INTO t_v2 VALUES ('a_gg');
可以看出在多表形成视图中哪怕只有一个字段也是需要加入字段名的。
INSERT INTO t_v1 ( t_name, t_flag_name ) VALUES ('a_g','b_g');
然后加全后就报错，无法插入超过一个表以上的视图，无论是否非显示字可以非空都会报错。
但是如果你插入的是虽然是两个表产生的视图，但是另一个表对呈现的数据没有任何作用，比如上面的t_v2；
-- 这个就无法通过视图 SELECT * FROM test_a查看了
-- 而是通过
SELECT * FROM test_a;
虽然没有显示但是t_flag 无法匹配 test_b中数据所以只能通过基表看。
可以看出这个虽然是两个表，但是字段只是一个表显示字段没有用另一个表的，所以可以看成一个表。
现在看一下如果删除的话：
DELETE FROM t_v1;
可以看出无法删除多表关联生存的视图。
现在试一下
DELETE FROM t_v2;
虽然插入的数据t_v2可以成功，但是删除就报错。
至于添加默认和非空这个限制就不在多表中体现了，而是在单表演示了。
其实t_v2有点像是用了子查询的意思了，不过还是不同的。现在重新来一个，不过子查询也有两种情况，一种是子查询作为一个条件存在，一个是子查询作为一个字段。
-- 这一种有人会让其放入一对一的关系中
CREATE VIEW t_v3 AS
SELECT t_name FROM test_a WHERE t_flag IN (SELECT t_flag FROM test_b) ;
update就不在演示了，这个其实除非不可改或者限制唯一然后更改了数据重复，一般都是可以用的，主要针对是插入和删除。
INSERT INTO t_v3 VALUES ('a_zc');
如果使用的是子查询，在插入的时候可以不带字段名。
所以就不用演示带字段名的了，现场尝试一下是否可以删除。
DELETE FROM t_v3 WHERE t_name='a_d';
可以看出可以删除，同时也影响了原表。
现在在来一个子查询，这个关联可以在FROM前面
CREATE VIEW t_v4 (t_name,t_flag_name) AS
SELECT t_name ,(SELECT test_b.`t_flag_name` FROM test_b WHERE test_b.`t_flag`=test_a.`t_flag` ) FROM test_a ;
插入就不尝试用前面无字段的，直接演示带字段的，因为带字段的都会报错，不要提不带字段的了
INSERT INTO t_v4 (t_name,t_flag_name) VALUES ('a_v4','b_v4');
插入都不靠谱，那就说实话删除也会报错
DELETE FROM t_v4;
对于一对一，这个很好理解就是视图本身通过一个表而生成视图，不过这个又会分好几种。如果不涉及任何运算，同时字段中没有非空的或者有非空限制但是又默认值的基表，通过其生成的视图完全可以增删改，而下面举的例子是插入删除的例子。
这个最常见的就是AVG,COUNT等所以只列出一个例子。
test_a表的内容恢复到初始化。
CREATE VIEW t_v5 AS
SELECT t_flag,COUNT(t_flag) t_count FROM test_a GROUP BY t_flag;
现在尝试一下是否可以更新：
UPDATE t_v5 SET t_flag='5' WHERE t_flag='1';
直接报错，那通过函数操作的t_count就更不用演示更新了，这个也会报错的。
现在尝试一下插入和删除。
INSERT INTO t_v5 VALUES ('11','12');
这种不会报错其没有限制字段，而是直接报错不可以插入数据。
INSERT INTO t_v5 (t_flag,t_count) VALUES ('11','12');
-- 和不带字段的报错一样，所以不在截图
可以删除吗？
DELETE FROM t_v5 WHERE t_flag='1'
可见也无法删除。所以说有了聚合函数只能更新无法插入和删除。
在聚合函数中演示的时候说无法插入和删除，一般使用HAVING的时候常与函数搭配使用，但是目前不考虑效率讲HAVING只作为一个类似WHERE的操作呢？
CREATE VIEW t_v6 AS
SELECT t_flag FROM test_a HAVING t_flag>'1' ;
更新尝试：
UPDATE t_v6 SET t_flag='5' WHERE t_flag='3'
更新都无法操作，为什么会这样呢？虽然讲HAVING当作一个WHERE使用，但是其在SQL中读取的顺序中还是GTOUP BY 等后面，所以前面都无法插入后面的就更不可能会允许更改了，后面的插入和删除就不在演示了，毕竟更新要求最低都不满足插入和删除更不可能了。
CREATE VIEW t_v7 AS
SELECT DISTINCT t_id FROM test_a
其实为了体现DISTINCT应该使用的字段是t_flag,但是为了演示哪怕这个DISTINCT关键没有意义，但是其还是会影响增改删。
UPDATE t_v7 SET t_id='5' WHERE t_id='1'
看这个就不允许演示插入和删除了吧，还是老话要求最低的你都满足不了，要求更高的就不要想了。
有时候记前面的有点复杂个人总结记住虽然不敢说全，但是好记够用。
两表以上相关联，无论通过join还是子查询，删除插入不要想。
还有一种怪现象，两表想联呈现字段为一表可插不可删。
更新要求它最低，两表以上就不提哪怕一表有函数，HAVING，DISTINCT等增删改就莫想了。
没有上面的限制，基表只唯一，查看字段是否有限制。
这个有两种 第一种：
CREATE OR REPLACE VIEW 视图名
[字段]
as
查询语句
第二种：
ALTER VIEW 视图名
as
查询语句
这个是整体将视图修改了，比如增加字段或者修改再视图中呈现的字段名。这个感觉有点像是将视图又重新生成了一遍。
删除视图只是删除视图的定义，并不会删除基表的数据。（是drop 而非delete ）
--
DROP VIEW [IF EXISTS] 视图名
--
DROP VIEW [IF EXISTS] 视图名1，视图名2………………
如果是基于视图创建的视图，如果刹车删除所谓的假基表（视图）也会导致基于假基表视图无法查询出数据，所以需要清楚这个关系。
类推也就是如果删除基表也会影响视图的查询。
优点
缺点
视图本身是依托基表的，所以基表的修改都会影响视图，有时候修改过大可能需要即使对相关的视图进行维护。有些是视图上创建视图，这样套娃的方式让其维护变得比较负责，可读性不是很友好。
视图可以重新定义字段名，还可以包含复杂的逻辑，这些都会增加维护成本。
所以视图是否需用这个需要，需要依托于自己的项目是否需要以及公司要求。