阅读量:0
文章目录
1.视图
视图是一个虚拟表，其内容由查询定义。同真实的表一样，视图包含一系列带有名称的列和行数据。
视图的数据变化会影响到基表，基表的数据变化也会影响到视图。
基本使用
创建视图
create view 视图名 as select语句； 案例
create view v_ename_dname as select ename, dname from EMP, DEPT where EMP.deptno=DEPT.deptno; select * from v_ename_dname order by dname; +--------+------------+ | ename | dname | +--------+------------+ | CLARK | ACCOUNTING | | KING | ACCOUNTING | | MILLER | ACCOUNTING | | SMITH | RESEARCH | | JONES | RESEARCH | | SCOTT | RESEARCH | | ADAMS | RESEARCH | | FORD | RESEARCH | | ALLEN | SALES | | WARD | SALES | | MARTIN | SALES | | BLAKE | SALES | | TURNER | SALES | | JAMES | SALES | +--------+------------+ 修改了视图，对基表数据有影响
select emp.ename, dept.dname, dept.deptno from emp,dept where emp.deptno=dept.deptno order by dname; update v_ename_dname set ename='TEST' where ename='CLARK'; select * from EMP where ename='CLARK'; select * from EMP where ename='TEST'; 修改了基表，对视图有影响
mysql> update EMP set deptno=10 where ename='JAMES'; -- 修改基表 Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select * from v_ename_dname where ename='JAMES'; +-------+----------+ | ename | dname | +-------+----------+ | JAMES | RESEARCH | <== 视图中的数据也发生了变化 +-------+----------+ 删除视图
drop view 视图名； 视图规则和限制
与表一样，必须唯一命名（不能出现同名视图或表名）
创建视图数目无限制，但要考虑复杂查询创建为视图之后的性能影响
视图不能添加索引，也不能有关联的触发器或者默认值
视图可以提高安全性，必须具有足够的访问权限
order by可以用在视图中，但是如果从该视图检索数据中的order by将被覆盖
视图可以和表一起使用
实战OJ
牛客：针对actor表创建视图actor_name_view
2.MySQL中的视图
View是一种虚拟表，其内容由查询定义。同真实表（物理表）一样，视图包含行和列，但视图本身不包含数据。它是从一个或多个真实表中检索数据的SQL语句。当查询视图时，系统会根据定义视图的SQL语句来动态生成数据。
理解视图的关键点：
虚拟性：视图不是数据库中存储的数据集合，而是存储在数据库中的SQL查询语句。当对视图进行查询时，数据库会执行这些查询语句并返回结果。
安全性：视图可以限制用户对数据的访问，只显示给用户他们应该看到的数据。例如，可以创建一个只包含员工姓名和职位的视图，而不包含薪资信息，以保护敏感数据。
逻辑数据独立性：当真实表的结构发生变化时（如添加、删除或修改列），只要视图的查询语句仍然有效，视图的结构就不会受到影响。这有助于在数据库结构变化时维护应用程序的稳定性。
简化复杂查询：视图可以封装复杂的SQL查询，使得用户能够像查询简单表一样查询复杂的数据。这对于经常需要执行复杂查询的应用程序来说非常有用。
更新限制：虽然可以像查询表一样查询视图，但并非所有视图都支持更新操作（如INSERT、UPDATE、DELETE）。视图的更新能力取决于其定义方式以及底层表是否允许更新。
使用视图的场景：
数据抽象：隐藏复杂的SQL查询，只展示用户需要看到的数据。
数据安全性：限制对数据的访问，确保用户只能看到他们被授权的数据。
逻辑数据组织：将相关数据组合在一起，即使它们存储在多个表中。
报表和数据分析：为复杂的数据分析提供简单的查询接口。
注意事项：
当对视图进行更新操作时，必须确保这些操作在底层表上也是有效的，并且不会导致数据不一致。
视图可以提高查询效率，但也可能导致性能下降，特别是当视图基于复杂的查询或包含大量数据时。
视图可以嵌套，即一个视图可以基于另一个视图定义，但过深的嵌套可能会导致查询难以理解和维护。
3.视图中的order by
在MySQL中，视图（View）本身并不直接存储数据，而是存储了一个SQL查询语句。这个查询语句定义了如何从基础表（或其他视图）中检索数据来“呈现”视图的内容。因此，当你尝试在视图中直接使用ORDER BY子句时，实际上是在定义这个查询语句时包含了排序逻辑。
然而，有一个重要的点需要注意：当你在视图定义中包含ORDER BY子句时，这个排序逻辑可能并不会像你预期的那样工作。原因在于，当你从视图中检索数据时，除非你在外部查询中也明确指定了ORDER BY，否则视图中定义的ORDER BY可能不会生效。
这是因为，当MySQL执行视图查询时，它首先会执行视图定义中的查询（包括任何内部的ORDER BY），但这只是为了生成视图的内容。然后，当你从视图中检索数据时，MySQL会执行一个外部查询来“读取”视图的内容。如果这个外部查询没有自己的ORDER BY子句，那么最终的结果集可能不会按照视图内部定义的顺序来排序。
举个例子：
CREATE VIEW my_view AS SELECT id, name, age FROM users ORDER BY age DESC; -- 当你这样查询视图时： SELECT * FROM my_view; -- 结果可能不会按照age降序排列，除非MySQL优化器决定保留这个顺序（但这通常不是可依赖的行为）。 -- 为了确保结果按预期排序，你应该在外部查询中也指定ORDER BY： SELECT * FROM my_view ORDER BY age DESC; order by可以用在视图中，但是如果从该视图检索数据中的order by将被覆盖。
因此，虽然你可以在视图定义中包含ORDER BY子句，但最好将其视为视图定义的一部分，而不是最终查询结果的强制排序。如果你希望确保从视图中检索的数据是排序的，你应该在查询视图时明确指定ORDER BY子句。
另外，值得注意的是，在某些数据库系统中（虽然MySQL不是这种情况），视图定义中的ORDER BY可能会被视为语法错误或不被支持，因为视图通常被认为是数据的一个逻辑子集，而不是具有特定顺序的数据集。然而，在MySQL中，虽然可以在视图定义中包含ORDER BY，但它通常不会影响最终的查询结果，除非你在查询视图时也明确指定了排序逻辑。
