视图（VIEW）的创建、使用与性能考量

视图：数据库中的“变脸大师”🎭—— 创建、使用与性能考量

各位观众，掌声欢迎！今天，咱们要聊聊数据库里的一个神奇存在——视图（VIEW）。 别看它名字平平无奇，实际上却是个“变脸大师”，能将复杂的数据化繁为简，让咱们的查询工作变得轻松愉快。

想象一下，你走进一家高档餐厅，服务员递给你一本厚厚的菜单，密密麻麻地排列着各种菜品，看得你眼花缭乱。 别慌！ 这时候，如果服务员再给你一份“今日推荐”，是不是瞬间感觉轻松多了？ 视图，就像是数据库的“今日推荐”，它从复杂的底层数据中提取出你最需要的信息，用一种更友好的方式呈现给你。

那么，视图到底是什么？它又有什么用？ 咱们今天就来好好扒一扒它的底裤，呸，是底细！

第一幕：揭开视图的神秘面纱 🤔

啥是视图？

简单来说，视图就是一个虚拟的表。 它并不存储实际的数据，而是基于一个或多个表（甚至是其他视图）的查询结果动态生成的。你可以把它理解成一个预先定义好的查询语句，每次你访问视图，数据库都会执行这个查询，然后把结果返回给你。

视图的本质：存储的是查询逻辑，而非数据！

举个栗子：

假设我们有一个 employees 表，包含员工的姓名（name）、部门（department）和薪水（salary）等信息。

CREATE TABLE employees (
    id INT PRIMARY KEY,
    name VARCHAR(255),
    department VARCHAR(255),
    salary DECIMAL(10, 2)
);

INSERT INTO employees (id, name, department, salary) VALUES
(1, '张三', '研发部', 10000.00),
(2, '李四', '销售部', 8000.00),
(3, '王五', '研发部', 12000.00),
(4, '赵六', '市场部', 9000.00),
(5, '钱七', '销售部', 9500.00);

现在，如果我们只想查看研发部员工的姓名和薪水，就可以创建一个视图：

CREATE VIEW developers AS
SELECT name, salary
FROM employees
WHERE department = '研发部';

以后，我们就可以像访问普通表一样访问这个视图：

SELECT * FROM developers;

数据库会自动执行视图的定义查询，返回研发部员工的姓名和薪水。

视图的优点：

• 简化查询： 将复杂的查询封装成简单的视图，方便用户访问。就像“今日推荐”一样，让你不用在茫茫菜品中大海捞针。
• 保护数据： 可以通过视图限制用户访问某些敏感数据，只允许他们查看特定字段或满足特定条件的数据。 就像餐厅只允许你看到菜名和价格，但不会告诉你大厨的独家秘方。
• 提高数据一致性： 如果多个查询都需要使用相同的数据子集，可以将其定义成一个视图，确保所有查询都使用相同的数据逻辑。 就像餐厅的菜品都使用统一的调味料，保证口味一致。
• 增强灵活性： 如果底层表结构发生变化，只需要修改视图的定义，而不需要修改所有引用该表的查询。 就像餐厅更换了新的餐具，但菜品的味道还是一样的。

第二幕：视图的百变造型 💃—— 创建视图的各种姿势

创建视图的语法非常简单：

CREATE [OR REPLACE] VIEW view_name AS
SELECT column1, column2, ...
FROM table_name
WHERE condition;

• CREATE VIEW：创建视图的关键字。
• OR REPLACE：如果视图已经存在，则替换它。
• view_name：视图的名称。
• SELECT：定义视图的查询语句。
• FROM：指定视图基于的表。
• WHERE：指定视图的数据过滤条件。

视图的种类：

视图可不是只有一种形态，它们根据不同的特性可以分为不同的类型：

• 简单视图： 基于单个表创建，只包含表中的列，不包含聚合函数或表达式。 就像餐厅只提供简单的凉拌菜，食材新鲜，原汁原味。
• 复杂视图： 基于多个表创建，或者包含聚合函数、表达式等复杂逻辑。 就像餐厅的招牌菜，融合了多种食材和烹饪技巧，风味独特。
• 物化视图（Materialized View）： 将视图的查询结果实际存储在磁盘上，而不是每次访问都重新计算。 就像餐厅提前准备好的半成品，可以更快地上菜。

创建视图的各种姿势：

• 简单的列选择：

  CREATE VIEW employee_names AS
  SELECT name FROM employees;

  这个视图只包含员工的姓名。

• 过滤特定数据：

  CREATE VIEW high_salary_employees AS
  SELECT name, salary
  FROM employees
  WHERE salary > 10000;

  这个视图只包含薪水高于 10000 的员工信息。

• 连接多个表：

  假设我们还有一个 departments 表，包含部门的 ID（id）和名称（name）。

  CREATE TABLE departments (
      id INT PRIMARY KEY,
      name VARCHAR(255)
  );
  
  INSERT INTO departments (id, name) VALUES
  (1, '研发部'),
  (2, '销售部'),
  (3, '市场部');

  我们可以创建一个视图，将员工表和部门表连接起来，显示员工的姓名和所属部门的名称：

  CREATE VIEW employee_department AS
  SELECT e.name AS employee_name, d.name AS department_name
  FROM employees e
  JOIN departments d ON e.department = d.name;

• 使用聚合函数：

  CREATE VIEW average_salary_by_department AS
  SELECT department, AVG(salary) AS average_salary
  FROM employees
  GROUP BY department;

  这个视图显示每个部门的平均薪水。

• 创建物化视图： (不同数据库的语法可能略有不同)

  CREATE MATERIALIZED VIEW materialized_average_salary_by_department AS
  SELECT department, AVG(salary) AS average_salary
  FROM employees
  GROUP BY department;

  这个视图会将计算结果存储在磁盘上，下次访问时可以直接读取，而不需要重新计算。 注意，物化视图需要定期刷新才能保持数据同步。

第三幕：视图的正确打开方式 🕹️—— 如何使用视图

视图的使用方法和普通表基本相同，可以使用 SELECT 语句查询视图中的数据：

SELECT * FROM view_name;

也可以在 WHERE 子句中使用视图进行过滤：

SELECT * FROM view_name WHERE condition;

还可以将视图与其他表或视图进行连接：

SELECT * FROM view_name1 JOIN view_name2 ON condition;

视图的可更新性：

并非所有的视图都可以进行更新操作（INSERT、UPDATE、DELETE）。 视图的可更新性取决于视图的定义：

• 可更新的视图：

  • 基于单个表创建。
  • 不包含聚合函数、DISTINCT、GROUP BY 或 HAVING 子句。
  • 不包含 UNION、UNION ALL、INTERSECT 或 EXCEPT 运算符。
  • SELECT 列表中不包含表达式。

  如果视图满足以上条件，就可以像更新普通表一样更新视图中的数据。

• 不可更新的视图：

  如果视图不满足以上条件，就不能直接更新视图中的数据。 通常情况下，你需要直接更新视图所基于的底层表。

更新视图的注意事项：

• 更新视图实际上是在更新视图所基于的底层表。
• 更新视图可能会影响其他使用该表的查询。
• 在更新视图之前，最好先备份数据。

第四幕：视图的性能优化之道 🚀—— 如何让视图飞起来

虽然视图可以简化查询，但如果使用不当，也会影响数据库的性能。 就像餐厅的“今日推荐”如果推荐的菜品制作时间过长，也会让顾客等得不耐烦。

影响视图性能的因素：

• 视图的复杂度： 视图的定义越复杂，查询视图的开销就越大。
• 底层表的性能： 如果底层表的查询效率不高，视图的性能也会受到影响。
• 数据量： 如果底层表的数据量很大，查询视图的开销也会很大。

优化视图性能的技巧：

• 尽量创建简单的视图： 避免在视图中使用复杂的查询逻辑，可以将复杂的查询分解成多个简单的视图。就像餐厅的“今日推荐”尽量选择制作简单的菜品，可以更快地上菜。
• 使用索引： 在底层表上创建适当的索引，可以提高视图的查询效率。就像餐厅提前准备好常用的食材，可以加快烹饪速度。
• 优化查询语句： 确保视图的定义查询语句是经过优化的，可以使用 EXPLAIN 语句分析查询计划，找出性能瓶颈。就像餐厅的大厨不断改进烹饪方法，提高效率。
• 使用物化视图： 对于频繁访问且数据变化不频繁的视图，可以考虑使用物化视图，将查询结果存储在磁盘上，避免重复计算。就像餐厅提前准备好半成品，可以更快地上菜。 但是，需要注意定期刷新物化视图，以保持数据同步。
• *避免在视图中使用 `SELECT `：** 只选择需要的列，可以减少数据传输量，提高查询效率。就像餐厅只推荐你感兴趣的菜品，避免让你浪费时间浏览不相关的菜单。
• 合理使用连接： 如果视图需要连接多个表，尽量使用 INNER JOIN，避免使用 OUTER JOIN，除非确实需要。就像餐厅尽量选择搭配合适的食材，避免使用味道冲突的食材。
• 利用查询重写： 某些数据库会自动将对视图的查询重写为对底层表的查询，从而优化查询性能。 你需要了解你的数据库是否支持查询重写，以及如何启用它。

表格总结：优化视图性能的常见技巧

技巧	描述	适用场景
创建简单视图	将复杂的查询分解成多个简单的视图，降低查询开销。	视图定义复杂，查询效率较低。
使用索引	在底层表上创建适当的索引，加快数据访问速度。	视图查询需要访问大量数据，且经常使用某些列进行过滤。
优化查询语句	使用 EXPLAIN 语句分析查询计划，找出性能瓶颈，并进行优化。	视图查询效率较低，需要找出性能瓶颈并进行优化。
使用物化视图	将视图的查询结果存储在磁盘上，避免重复计算。	视图查询频繁，数据变化不频繁。
避免 SELECT *	只选择需要的列，减少数据传输量。	视图查询只需要访问部分列。
合理使用连接	尽量使用 INNER JOIN，避免使用 OUTER JOIN，除非确实需要。	视图需要连接多个表。
利用查询重写	了解数据库是否支持查询重写，并启用它，让数据库自动优化查询。	数据库支持查询重写，且视图的查询可以被重写为对底层表的查询。

第五幕：视图的维护与管理 🧹—— 如何保持视图的健康

视图创建好了，并不是一劳永逸的，还需要进行定期的维护和管理，才能保证视图的有效性和性能。 就像餐厅的“今日推荐”需要根据季节和食材的变化进行调整，才能吸引顾客。

视图的维护：

• 定期检查视图的定义： 确保视图的定义仍然有效，并且符合业务需求。 如果底层表结构发生变化，需要及时修改视图的定义。
• 监控视图的性能： 定期监控视图的查询性能，如果发现性能下降，需要及时进行优化。
• 清理无用的视图： 删除不再使用的视图，可以减少数据库的负担。

视图的管理：

• 使用规范的命名： 为视图选择一个清晰、易懂的名称，方便用户理解视图的作用。
• 添加注释： 为视图添加注释，说明视图的用途、包含的数据以及更新频率等信息。
• 进行权限管理： 控制用户对视图的访问权限，避免敏感数据泄露。

修改视图：

可以使用 ALTER VIEW 语句修改视图的定义：

ALTER VIEW view_name AS
SELECT column1, column2, ...
FROM table_name
WHERE condition;

删除视图：

可以使用 DROP VIEW 语句删除视图：

DROP VIEW view_name;

注意事项：

• 删除视图不会影响底层表的数据。
• 删除视图会影响所有引用该视图的查询。

尾声：视图，数据库的得力助手 🤝

总而言之，视图是数据库中一个非常强大的工具，可以简化查询、保护数据、提高数据一致性以及增强灵活性。 只要你掌握了视图的创建、使用和性能优化技巧，就能让它成为你数据库管理的得力助手。

希望今天的讲解对大家有所帮助！ 如果你还有其他问题，欢迎在评论区留言，我会尽力解答。

感谢大家的收看！ 我们下期再见！ 👋