MySQL视图之：`视图`的`底层`实现：`视图`是`SQL`语句的存储还是数据的物理存储。 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

MySQL视图：SQL语句存储的逻辑抽象

各位同学，大家好！今天我们来深入探讨MySQL视图的底层实现。关于视图，一个核心问题就是：视图究竟是SQL语句的存储，还是数据的物理存储？答案是，视图本质上是SQL语句的存储，它并不实际存储数据，而是提供了一个逻辑层，将复杂的查询封装起来，简化用户的操作。

视图的概念与优势

首先，我们快速回顾一下视图的概念。视图是一个虚拟表，它的内容由查询定义。这个查询可以来自一个或多个表，甚至可以来自其他的视图。

视图的主要优势包括：

简化查询： 隐藏复杂的连接、聚合等操作，用户只需简单地查询视图即可获取所需数据。
数据安全： 限制用户对底层表的直接访问，只允许通过视图访问部分数据，提高数据的安全性。
数据一致性： 如果底层表的结构发生变化，只需要修改视图的定义，而不需要修改所有依赖于这些表的应用程序。
重用性： 相同的查询逻辑可以被多个用户或应用程序重用，提高开发效率。

视图的底层实现：SQL语句存储

关键在于理解视图的底层实现。当我们创建一个视图时，MySQL实际上存储的是视图的定义，也就是创建视图的SQL语句。当用户查询视图时，MySQL会将视图的定义与用户的查询语句合并，生成最终的查询计划，并执行这个计划来从底层表中获取数据。

让我们通过一个例子来说明：

-- 创建一个名为customer_orders的视图，显示客户姓名和订单总金额
CREATE VIEW customer_orders AS
SELECT c.customer_name, SUM(o.order_total) AS total_order_amount
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_name;

-- 查询视图
SELECT * FROM customer_orders;

在这个例子中，当我们执行CREATE VIEW语句时，MySQL会存储以下信息：

视图名称：customer_orders
视图定义：SELECT c.customer_name, SUM(o.order_total) AS total_order_amount FROM customers c JOIN orders o ON c.customer_id = o.customer_id GROUP BY c.customer_name

当我们执行SELECT * FROM customer_orders时，MySQL会执行以下步骤：

获取customer_orders视图的定义。

将视图的定义替换到查询语句中，相当于执行以下语句：

SELECT * FROM (SELECT c.customer_name, SUM(o.order_total) AS total_order_amount FROM customers c JOIN orders o ON c.customer_id = o.customer_id GROUP BY c.customer_name) AS customer_orders;

优化并执行这个查询语句，从customers和orders表中获取数据，并返回结果。

因此，我们可以看到，视图本身并不存储任何数据，它只是一个SQL查询语句的“快捷方式”。

物化视图与非物化视图

为了更深入地理解视图的实现，我们需要区分物化视图和非物化视图。

非物化视图（Non-Materialized View）： 这就是我们通常所说的视图，它只存储查询定义，不存储数据。每次查询视图时，都需要重新执行查询定义来获取数据。MySQL中的标准视图都是非物化视图。
物化视图（Materialized View）： 物化视图会实际存储查询结果。当底层表的数据发生变化时，物化视图需要进行刷新，以保持数据的一致性。MySQL本身原生不支持物化视图，但可以通过一些第三方工具或手动实现类似的功能。

特性	非物化视图 (标准视图)	物化视图
数据存储	不存储数据	存储数据
数据一致性	实时，反映底层表变化	需要刷新才能保持与底层表的一致性
查询性能	每次查询都需要重新计算	查询速度快，因为数据已经预先计算并存储
数据更新	不支持直接更新	需要通过刷新操作来更新数据
资源消耗	资源消耗较少	占用额外的存储空间，需要定期刷新，消耗计算资源
MySQL原生支持	支持	不支持，需要借助第三方工具或手动实现

物化视图的模拟实现（手动刷新）

由于MySQL原生不支持物化视图，我们可以通过以下方式模拟物化视图的功能：

创建一张实际的表来存储视图的结果。
编写一个存储过程或定时任务，定期执行视图的查询语句，并将结果插入或更新到这张表中。

-- 1. 创建存储结果的表
CREATE TABLE materialized_customer_orders AS
SELECT c.customer_name, SUM(o.order_total) AS total_order_amount
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_name;

-- 2. 创建存储过程来刷新数据
DELIMITER //
CREATE PROCEDURE refresh_customer_orders()
BEGIN
    TRUNCATE TABLE materialized_customer_orders; -- 清空表
    INSERT INTO materialized_customer_orders
    SELECT c.customer_name, SUM(o.order_total) AS total_order_amount
    FROM customers c
    JOIN orders o ON c.customer_id = o.customer_id
    GROUP BY c.customer_name;
END //
DELIMITER ;

-- 3. 调用存储过程来刷新数据
CALL refresh_customer_orders();

-- 4. 定时执行存储过程 (可以使用事件调度器)
-- 例如：每天凌晨1点刷新数据
-- CREATE EVENT refresh_customer_orders_event
-- ON SCHEDULE EVERY 1 DAY
-- STARTS CURRENT_DATE + INTERVAL 1 DAY + INTERVAL 1 HOUR
-- DO CALL refresh_customer_orders();

这种方法虽然可以实现类似物化视图的功能，但需要手动维护数据的一致性，并且需要额外的存储空间。

视图的可更新性

并非所有的视图都是可更新的。一个视图是否可更新，取决于其定义是否满足以下条件：

视图必须是基于单个表构建的。
视图不能包含聚合函数（如SUM、AVG、COUNT等）。
视图不能包含GROUP BY、HAVING或DISTINCT子句。
视图不能包含UNION或UNION ALL子句。
视图不能包含子查询。

如果一个视图满足以上条件，那么我们可以像操作普通表一样，对视图进行INSERT、UPDATE和DELETE操作。这些操作实际上会被转换为对底层表的操作。

例如，假设我们有一个名为active_customers的视图，定义如下：

CREATE VIEW active_customers AS
SELECT customer_id, customer_name, email
FROM customers
WHERE is_active = 1;

我们可以对active_customers视图进行更新操作：

UPDATE active_customers SET email = '[email protected]' WHERE customer_id = 123;

这个UPDATE语句实际上会被转换为对customers表的更新操作：

UPDATE customers SET email = '[email protected]' WHERE customer_id = 123 AND is_active = 1;

如果视图不满足可更新的条件，那么对视图的更新操作将会失败。

视图的权限管理

视图可以用于限制用户对底层表的访问权限。我们可以授予用户对视图的查询权限，而拒绝用户对底层表的直接访问权限。这样，用户只能通过视图来访问部分数据，从而提高数据的安全性。

例如，我们可以创建一个名为employee_salaries的视图，只显示员工的姓名和部门，而不显示薪水信息：

CREATE VIEW employee_salaries AS
SELECT employee_name, department
FROM employees;

然后，我们可以授予用户对employee_salaries视图的查询权限，而拒绝用户对employees表的直接访问权限：

GRANT SELECT ON employee_salaries TO 'user'@'localhost';
REVOKE SELECT ON employees FROM 'user'@'localhost';

这样，用户只能通过employee_salaries视图来查看员工的姓名和部门，而无法直接访问employees表来查看薪水信息。

视图的优化

虽然视图可以简化查询，但过度使用视图可能会导致性能问题。因为每次查询视图时，都需要重新执行视图的定义。为了优化视图的性能，我们可以考虑以下几点：

避免创建过于复杂的视图： 尽量保持视图的定义简洁明了，避免嵌套过多的子查询或连接操作。
使用索引： 在底层表的关键字段上创建索引，可以提高查询性能。
考虑使用物化视图： 如果查询频率很高，且数据变化不频繁，可以考虑使用物化视图来提高查询性能。
优化查询语句： 确保查询语句的效率，避免全表扫描。

总结一下

视图本质上是SQL语句的存储，而不是数据的物理存储。理解视图的底层实现，有助于我们更好地利用视图来简化查询、提高数据安全性和一致性。虽然MySQL原生不支持物化视图，但我们可以通过一些方法来模拟物化视图的功能。在实际应用中，我们需要根据具体情况选择合适的视图类型，并注意视图的优化，以确保查询性能。