如何在SQL中创建视图？VIEW的定义与使用场景解析

SQL中的视图（VIEW）本质上是一个虚拟表，它不存储任何实际数据，而是保存了一段预定义的SQL查询语句。每次你查询这个视图时，数据库系统都会实时执行其底层的查询逻辑，并返回最新的结果集。你可以把它想象成一个定制的“窗口”，透过这个窗口，你只能看到底层数据的一个特定切面，其核心价值在于简化复杂查询、增强数据安全性以及提供灵活的数据抽象层。

解决方案

要在SQL中创建视图，你主要会用到

CREATE VIEW

SELECT

一个基本的视图创建语法如下：

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

让我们通过一个实际的例子来理解。假设我们有一个

Employees

Departments

创建视图的示例：

-- 假设我们有这两个表
-- CREATE TABLE Employees (
--     EmployeeID INT PRIMARY KEY,
--     FirstName VARCHAR(50),
--     LastName VARCHAR(50),
--     DepartmentID INT,
--     Salary DECIMAL(10, 2),
--     IsActive BIT
-- );

-- CREATE TABLE Departments (
--     DepartmentID INT PRIMARY KEY,
--     DepartmentName VARCHAR(50)
-- );

-- 插入一些示例数据
-- INSERT INTO Departments (DepartmentID, DepartmentName) VALUES (1, 'Sales'), (2, 'Marketing'), (3, 'HR');
-- INSERT INTO Employees (EmployeeID, FirstName, LastName, DepartmentID, Salary, IsActive) VALUES
-- (101, '张', '三', 1, 60000.00, 1),
-- (102, '李', '四', 1, 75000.00, 1),
-- (103, '王', '五', 2, 58000.00, 1),
-- (104, '赵', '六', 3, 62000.00, 0); -- 赵六不活跃

-- 创建一个视图来展示销售部门的活跃员工信息
CREATE VIEW ActiveSalesEmployees AS
SELECT
    e.EmployeeID,
    e.FirstName,
    e.LastName,
    d.DepartmentName,
    e.Salary
FROM
    Employees e
JOIN
    Departments d ON e.DepartmentID = d.DepartmentID
WHERE
    d.DepartmentName = 'Sales' AND e.IsActive = 1;

一旦视图创建成功，你就可以像查询普通表一样查询它：

SELECT * FROM ActiveSalesEmployees;

这将返回张三和李四的信息，因为他们是销售部门的活跃员工。

如果你需要修改一个已存在的视图，可以使用

ALTER VIEW

ALTER VIEW ActiveSalesEmployees AS
SELECT
    e.EmployeeID,
    e.FirstName,
    e.LastName,
    d.DepartmentName,
    e.Salary,
    'Active' AS Status -- 添加一个状态列
FROM
    Employees e
JOIN
    Departments d ON e.DepartmentID = d.DepartmentID
WHERE
    d.DepartmentName = 'Sales' AND e.IsActive = 1;

而当视图不再需要时，可以通过

DROP VIEW

DROP VIEW ActiveSalesEmployees;

需要注意的是，虽然视图可以像表一样被查询，但并非所有视图都支持

INSERT

UPDATE

DELETE

GROUP BY

DISTINCT

视图与表有什么本质区别？VIEW的优势和局限性有哪些？

视图和表在数据库中扮演着截然不同的角色，理解它们之间的本质区别是高效利用视图的关键。简单来说，表是实际存储数据的物理结构，数据就实实在在地躺在那里。而视图则是一个虚拟结构，它本身不存储任何数据，仅仅是底层SQL查询的一个命名表示。每次你查询视图，数据库都会重新执行那个定义视图的SQL查询，然后把结果呈现给你。

从这个核心差异出发，视图的优势和局限性就变得清晰起来了：

VIEW的优势：

1. 简化复杂查询： 这是视图最直观的好处。想象一下，如果你的应用程序需要频繁地从十几个表进行JOIN操作，再进行复杂的WHERE条件过滤和聚合计算。每次都写这么长的SQL语句不仅耗时，还容易出错。把这些复杂逻辑封装在一个视图里，应用程序只需要简单地

   SELECT * FROM MyComplexReportView;

   登录后复制
   ，代码会变得极其简洁和可维护。对我来说，这就像是给复杂逻辑起了一个好听的名字，让别人更容易理解和使用。
2. 增强数据安全性： 视图提供了一个强大的安全层。你可以精确控制用户只能访问视图中定义的特定列和行，而无需授予他们底层表的全部权限。例如，你可以创建一个视图，只包含员工的姓名和部门，但不包括薪资或联系方式，然后只允许HR部门访问包含薪资的视图。这样，敏感数据就被有效地隐藏起来了。这比直接在表级别控制权限要精细得多。
3. 提供数据抽象和一致性： 视图可以为不同的用户或应用程序提供不同的数据视角，即使底层数据源是同一个。当底层表结构发生变化时（比如增加了一个字段，或者将一个大表拆分成两个小表），只要视图的定义保持不变，依赖于该视图的应用程序就无需修改。这大大提高了应用程序的健壮性和可维护性，降低了耦合度。在处理遗留系统或者数据库重构时，视图简直是救命稻草。
4. 逻辑数据独立性： 这是上一点的延伸。视图允许你在不影响应用程序的情况下，修改底层表的物理结构。例如，你可能将一个大表拆分成多个小表，或者改变了列名。只要你创建的视图能够模拟出旧的表结构，应用程序就可以继续正常工作。

VIEW的局限性：

1. 性能开销： 视图本身不存储数据，所以每次查询视图，数据库都需要执行其底层查询。如果底层查询非常复杂，涉及大量JOIN和聚合，那么查询视图可能会比直接查询优化过的表要慢。这就像你每次点餐都要厨师从头开始准备食材一样，而不是直接从预制菜中取出。对于性能敏感的场景，这是一个需要仔细权衡的点。
2. 更新限制： 并非所有视图都是“可更新”的。通常，如果视图的底层查询包含

   JOIN

   登录后复制
   、

   DISTINCT

   登录后复制
   、

   GROUP BY

   登录后复制
   、聚合函数（如

   SUM

   登录后复制
   、

   COUNT

   登录后复制
   ）或子查询，那么你就不能通过视图来

   INSERT

   登录后复制
   、

   UPDATE

   登录后复制
   或

   DELETE

   登录后复制
   数据。这是因为数据库无法明确知道这些操作应该如何映射回底层的物理表。试图对不可更新的视图进行数据修改操作会导致错误。
3. 依赖性： 视图是依赖于底层表的。如果底层表被重命名、删除，或者其列结构发生重大变化，那么视图可能会失效，导致查询错误。维护视图时，需要关注其依赖关系。
4. 索引限制： 视图本身通常没有自己的索引。视图的性能优化依赖于其底层表的索引。虽然某些数据库系统支持“物化视图”（Materialized View），它会存储查询结果并可以创建索引，但这会增加存储空间和数据同步的复杂性。

总的来说，视图是一把双刃剑，它能极大地简化开发和提高安全性，但在性能和可更新性方面需要谨慎考虑。

在哪些实际场景下，使用SQL视图能带来显著效益？

视图的价值往往体现在它能够优雅地解决实际业务中的复杂问题，而不仅仅是技术上的炫技。以下是一些我个人觉得视图能带来显著效益的场景：

通义视频

通义万相AI视频生成工具

70

查看详情

1. 精细化权限管理与数据安全：

   • 场景： 一个大型企业数据库，不同部门（销售、市场、财务）需要访问相同的客户数据，但每个部门只能看到自己业务相关的部分，甚至同一部门内不同级别的员工也应有不同权限。
   • 视图应用： 创建多个视图，每个视图定义一个特定部门或角色所需的数据子集。
     • 例如，

       SalesLeadsView

       登录后复制
       可能只包含客户姓名、联系方式和潜在销售机会，不包含财务信息。

     • FinancialCustomersView

       登录后复制
       可能只包含客户ID、订单总额和支付状态，不包含个人隐私信息。
   • 效益： 通过授予用户对特定视图的访问权限，而不是直接访问底层表，可以极大地简化权限管理，确保数据安全，避免敏感信息泄露。这比在应用程序层面做数据过滤更靠近数据源，更安全可靠。

2. 简化复杂报表和数据分析：

   • 场景： 公司的业务分析师或BI工具需要定期生成复杂的报表，这些报表往往涉及多个表的JOIN、大量的聚合计算和复杂的筛选逻辑。
   • 视图应用： 将这些复杂的报表逻辑封装在一个或多个视图中。
     • 例如，一个

       MonthlySalesSummaryView

       登录后复制
       可以聚合不同区域、不同产品的月销售额和利润。

     • CustomerLifetimeValueView

       登录后复制
       可以计算每个客户的终身价值，涉及订单、退货、客户等级等多个维度。
   • 效益： 分析师或BI工具可以直接查询这些视图，而无需每次都重写或理解复杂的SQL。这不仅提高了工作效率，还保证了报表数据的一致性和准确性，因为所有人都基于相同的视图定义来获取数据。

3. 遗留系统维护与数据库重构：

   • 场景： 你的数据库结构需要升级或重构（例如，为了性能将一个大表拆分成多个小表，或者改变了某些列的命名），但现有的大量应用程序或报表仍然依赖旧的表结构。
   • 视图应用： 创建视图来模拟旧的表结构。
     • 如果旧表

       OldCustomers

       登录后复制
       被拆分为

       CustomerDetails

       登录后复制
       和

       CustomerAddresses

       登录后复制
       ，你可以创建一个名为

       OldCustomers

       登录后复制
       的视图，它JOIN这两个新表，并选择出与旧表相同的列。
   • 效益： 应用程序无需修改代码，仍然可以像访问旧表一样访问数据。这为数据库重构提供了极大的灵活性和缓冲期，降低了系统升级的风险和成本。这在大型企业环境中尤其有用，因为不可能一次性更新所有依赖。

4. 隐藏底层数据模型的复杂性：

   • 场景： 数据库设计可能非常复杂，包含许多规范化的表，以及一些为了性能而做的反规范化设计。对于不熟悉数据库结构的开发人员来说，直接操作这些表可能会感到困惑。
   • 视图应用： 为应用程序开发人员提供一个简化的、业务友好的数据接口。
     • 例如，一个

       ProductCatalogView

       登录后复制
       可以JOIN

       Products

       登录后复制
       、

       Categories

       登录后复制
       和

       Suppliers

       登录后复制
       表，只显示产品名称、类别名称、供应商名称和价格，隐藏了底层表ID和JOIN逻辑。
   • 效益： 开发人员可以更专注于业务逻辑，而不是数据库的物理结构，提高了开发效率和代码质量。它提供了一个“API”层，让数据消费者更容易理解和使用数据。

这些场景都体现了视图作为一种数据抽象工具的强大能力，它能够让数据库在满足多样化需求的同时，保持其核心数据的完整性和安全性。

创建和管理SQL视图时，有哪些性能优化和最佳实践？

创建和管理SQL视图并非只是简单地封装一段查询，要真正发挥其效能并避免潜在的性能陷阱，需要遵循一些最佳实践。我个人在工作中，尤其关注以下几点：

1. *只选择必要的列，避免`SELECT `：**

   • 实践： 在视图定义中，明确列出所有需要的列，而不是使用

     SELECT *

     登录后复制
     。
   • 原因与效益：

     SELECT *

     登录后复制
     会检索底层表的所有列，即使这些列在应用程序中根本用不到。这不仅增加了数据传输量，也可能导致数据库在执行查询时做更多不必要的I/O和内存操作。如果底层表后来添加了新列，

     SELECT *

     登录后复制
     的视图也会自动包含这些新列，这有时会导致应用程序意外地接收到不必要的数据，甚至引发兼容性问题。精确选择列可以减少开销，提高查询效率。

2. 优化底层查询：

   • 实践： 视图的性能直接取决于其底层

     SELECT

     登录后复制
     语句的性能。在创建视图之前，确保其核心查询本身已经经过充分优化。
   • 原因与效益： 这包括为JOIN条件、WHERE子句和ORDER BY子句中的列创建合适的索引。检查执行计划，确保没有全表扫描，JOIN操作高效。一个慢的底层查询，无论你把它封装在多少个视图里，它依然是慢的。视图只是一个“壳”，真正的性能瓶颈在“核”。

3. 避免过度嵌套视图：

   • 实践： 尽量减少视图的嵌套层级。如果一个视图A基于视图B，视图B又基于视图C，这样的多层嵌套可能导致查询优化器在解析和执行时遇到困难。
   • 原因与效益： 过多的嵌套会增加查询解析的复杂性，有时会阻止优化器进行有效的重写和优化。虽然现代数据库的优化器已经很智能了，但过度嵌套仍然可能导致性能下降。如果逻辑复杂到需要多层抽象，可以考虑将部分逻辑通过存储过程或函数来实现，或者重新设计数据模型。

4. 考虑物化视图（Materialized Views）：

   • 实践： 对于那些底层数据变化不频繁，但视图查询非常复杂且查询频率极高的场景，可以考虑使用物化视图（如果你的数据库系统支持，如Oracle、PostgreSQL、SQL Server的索引视图）。
   • 原因与效益： 物化视图会实际存储查询结果，并可以在其上创建索引，从而大大提高查询性能。但代价是，它需要定期刷新以保持数据最新，这会消耗资源。你需要权衡查询性能提升与刷新开销之间的平衡。这并非所有视图的通用解决方案，但对于特定场景是“银弹”。

5. 清晰的命名规范和文档：

   • 实践： 采用一致、有意义的命名约定（例如，

     vw_CustomerOrders

     登录后复制
     或

     v_ProductSalesSummary

     登录后复制
     ），并为复杂的视图添加注释，说明其目的、底层逻辑和依赖关系。
   • 原因与效益： 良好的命名和文档是代码可维护性的基石。当团队成员需要理解或修改视图时，清晰的命名和注释可以大大减少他们的认知负担，避免误用或不必要的重复创建。

6. 精确的权限控制：

   • 实践： 不要直接授予用户对底层表的权限，而是授予他们对特定视图的

     SELECT

     登录后复制
     权限。
   • 原因与效益： 这是视图在安全性方面最重要的应用。通过视图，你可以实现行级别和列级别的安全控制，确保用户只能访问其被授权的数据子集。这比在应用程序层面做权限控制更安全，因为数据层面的安全是最终的防线。

7. 定期审查和清理：

   • 实践： 定期检查数据库中存在的视图。移除那些不再使用、已过时或已被更优方案取代的视图。
   • 原因与效益： 数据库中堆积无用对象会增加管理复杂性，有时甚至可能引起混淆。保持数据库对象的整洁有序，有利于维护和性能。

8. 理解视图的可更新性限制：

   • 实践： 在设计视图时，要清楚地知道你的视图是否支持

     INSERT

     登录后复制
     、

     UPDATE

     登录后复制
     或

     DELETE

     登录后复制
     操作。如果业务逻辑需要通过视图进行数据修改，那么视图的底层查询必须足够简单，通常是基于单个表且不含聚合或复杂JOIN。
   • 原因与效益： 提前了解这些限制可以避免在开发过程中遇到不必要的错误和返工。如果视图不可更新，那么应用程序需要直接操作底层表，或者通过存储过程来封装修改逻辑。

通过这些实践，视图可以成为数据库设计中一个非常强大且灵活的工具，帮助我们构建更健壮、更安全、更易于维护的系统。

以上就是如何在SQL中创建视图？VIEW的定义与使用场景解析的详细内容，更多请关注php中文网其它相关文章！