当前位置：首页 > news >正文

视图是什么？有什么用？什么时候用？MySQL中的视图

news 2025/8/11 7:03:00

面试被问到视图相关的了，直接就是没听过，那么这会来了解一下什么是视图

mysql的视图是什么？什么时候会用到？怎么使用？什么时候出来的功能？现在还在用嘛？被什么技术替代了？优缺点是什么？

MySQL 的视图是什么？就是一段SQL语句，只不过是存到MySQL中去了，并给他给了个类型叫视图，存的时候也给他起了个别名，方便后续使用。用的时候就是通过视图名字拿到视图对应的SQL来执行，所以视图存的只是SQL，而不是SQL执行之后的数据，也因此视图所占的空间很小
什么时候会用到视图？ ①简化复杂查询(把复杂的SQL封装成视图，这有点像Java封装方法，只暴露方法名，入参出参那些，至于方法的细节不用操心) ②数据安全：对外提供视图而不是直接访问真实表，可以隐藏敏感字段（如手机号、身份证号）。 ③统一数据口径：把统计逻辑放到视图里，保证所有人取到的数据一致。 ④跨团队协作：DBA/数据开发定义好视图，业务只需要调用，不需要关心底层数据结构。

怎么使用视图？
创建视图：

create view view_name as select colume1,colume2, ... from table_name where condition

使用视图：

select * from view_name

修改视图：

alert view view_name as select ……

删除视图：

drop view view_name

什么时候出来的功能？视图是在MySQL5.0版本中出来的功能
现在还在用嘛？被什么技术替代了？应用层被一些新的技术替代了，比如MyBatis中的Mapper，还有Spring Data JPA中的Repository，这些技术都是基于视图的思想，只是实现方式不同，但是都是简化复杂查询，统一数据口径，跨团队协作在大数据/OLAP 场景中：用物化视图（Materialized View）、ETL 生成中间表来替代，减少实时计算压力。在权限控制上：用数据权限控制框架代替仅依赖视图隐藏敏感字段
缺点是什么？性能问题：每次查询视图都会执行底层 SQL，复杂视图可能很慢。不利于调优：优化 SQL 时可能需要分析多层嵌套视图，复杂度高。有些视图是只读的，不方便写操作。维护成本高：表结构变化可能导致视图失效。

那么我平常在这个navicate软件工具里面写一个查询语句，下面展示出来的数据就是视图？以及Mybatis和jpa是怎么对视图做处理的？

navicate软件工具里面写一个查询语句，下面展示出来的数据就是视图？不是的，那个数据只是指临时查询的结果，并没有在数据库中保存成对象，而试图是把这个SQL保存下来，可以作为虚拟表来使用
Mybatis和jpa是怎么对视图做处理的？ MyBatis MyBatis 把视图当成普通的表看待，只要数据库里存在这个视图，就可以直接在 mapper 里写：视图查询返回的列，必须和 resultType 或 resultMap 对应的字段匹配，否则会映射失败。 MyBatis 不关心你这个对象是表还是视图，只要数据库能查出来，它就能映射。

<select id="selectAdults" resultType="User"> SELECT * FROM adult_user </select>

JPA JPA 也可以把视图映射成实体类，做法和映射表是一样的：如果视图是只读的，JPA 的 save()、update() 会报错，因为底层数据库视图不支持写操作。对于可更新视图（单表、无聚合、无 DISTINCT 等限制），JPA 的写操作也可以生效，但要小心触发数据库限制。

@Entity @Table(name = "adult_user") // 对应视图名 public class AdultUser { private String name; private Integer age; }

哦哦我懂了，也就是视图其实就是一个SQL的查询语句是吧，是保存到MySQL中的SQL语句是不，然后买次调用视图的时候，都是在实行这个SQL语句，然后作为对应的视图名，以表格的形式返回出来，然后dba就是把那些复杂的SQL封装成视图存到MySQL中去，然后把对应的视图名称给开发，让他们去使用是不？那这么看视图还挺好用的，他有什么弊端嘛，以及生成的视图存到数据库的那个地方了？存储过程是不是跟视图有点类似啊

你理解的流程没错 ✅ 视图本质就是一个保存到 MySQL 里的 SELECT 查询语句，数据库给它起了个名字（视图名）。每次查询视图时，MySQL 会实时执行这个 SQL，然后把结果当作“表”一样返回。 ✅ 使用方式 DBA 负责写复杂 SQL → 存成视图（CREATE VIEW） → 给开发一个视图名。开发就可以直接 SELECT * FROM 视图，像查表一样简单。
视图存在哪？视图定义存放在数据库的元数据（data dictionary）里，而不是存数据的 .ibd 文件。在 MySQL 的物理文件结构中： .frm / 数据字典记录了视图的列结构 .view 文件里保存了视图的 SQL 定义也可以在 information_schema.VIEWS 表中看到视图的定义：

SELECT * FROM information_schema.VIEWS WHERE TABLE_NAME = 'your_view_name';

存储过程和视图的区别视图更像是“保存的 SQL 查询模板”。存储过程更像是“数据库里的一个小程序”，可以包含条件判断、循环、事务处理。

聚合、DISTINCT、UNION 等会让视图无法更新这个不太懂为什么另一个就是表结构有变化了，跟这个表有关的视图就会被删掉？另外我了解到的就是这个存储过程容易导致锁行、锁表的问题，但是这些问题是的原因我不清楚，另外是不是视图也会导致这些问题，那么现在市场中视图这个东西被用的多嘛？以及出现了这种行锁、表锁怎么处理解决，并调整这个视图或是别的来解决这个问题？为什么用视图不用存储过程，这两个在MySQL中的差别是什么？

为什么聚合、DISTINCT、UNION 会让视图无法更新？视图要支持 UPDATE/DELETE/INSERT，MySQL 必须能确定：这个视图的每一行数据，对应到底层表中的唯一一行。一旦存在聚合函数（SUM、COUNT、MAX...）、DISTINCT、GROUP BY、UNION 等，行与行之间已经是“汇总后的结果”，底层表的唯一对应行就消失了。举例： sql

CREATE VIEW v_sales AS SELECT product_id, SUM(price) AS total FROM orders GROUP BY product_id;

你要 UPDATE v_sales SET total = 100 时，数据库懵了：这个 total = 100 应该更新 orders 表的哪一行？有可能是 1 行、10 行甚至 100 行，所以 MySQL 直接禁止更新。简单说：视图只有是“单表 + 主键可唯一定位 + 没有复杂聚合”时才可更新。

表结构变化会怎样影响视图？字段被删除：视图引用了这个字段，查询会报错（Unknown column），但视图对象本身可能还在，只是不可用。字段改名：同上，视图报错。表被删除：视图变成“孤儿”，查询直接报错（Table doesn't exist）。表新增字段：视图不受影响，除非是 SELECT * 创建的视图，新增字段不会自动加进来（因为视图在创建时已经定死了字段列表）。
存储过程为什么容易导致锁行、锁表？原因不是“存储过程”本身，而是存储过程里的 SQL 逻辑可能引发锁：事务范围大：存储过程可能在一次调用中执行多条 DML（INSERT/UPDATE/DELETE）并开启事务，期间行或表会保持锁定。大批量更新：一次更新大量行，如果走全表扫描，可能会升级为表锁。无索引条件更新：UPDATE table SET ... WHERE 非索引字段=xxx，会锁更多行甚至全表。 📌 行锁、表锁在视图中也可能出现因为视图只是 SQL 的别名，如果你对视图执行更新，而底层 SQL 没有走索引、或涉及多表 join，本质还是会锁大量数据。

出现行锁/表锁怎么解决？常见优化思路：加索引确保 WHERE 条件走索引，减少锁的范围。减少事务持有锁时间不要在事务中夹杂大量逻辑或等待用户输入。拆分大事务为多个小事务。避免大批量一次更新用 LIMIT + 循环更新（分批更新）。用合适的事务隔离级别有些场景从 REPEATABLE READ 改为 READ COMMITTED 可以减少锁等待。必要时用物化表替代视图把复杂 SQL 结果提前计算好存到临时表，减少实时大范围锁。