视图：给复杂查询一个稳定入口

上一章讨论索引与约束时，我们一直在给表打地基：索引负责让数据库更快地找到行，约束负责阻止不合法的数据进入表。可当业务开始增长，另一个问题会越来越明显——表结构适合存储，却未必适合直接交给每一个使用者。

例如，一张订单报表可能要连接 customers、orders、order_items 和 products，还要统一计算折扣后的成交额；客服只应该看到客户所在城市，不该看到完整手机号和邮箱；应用程序已经依赖一组固定列名，底层表却正准备调整。让每个调用者各写一遍查询，不仅麻烦，还会让口径、权限和改动成本一起失控。

视图就是夹在“底层存储”与“上层使用”之间的稳定入口。它给一条查询命名，让使用者像查表一样查它。真正重要的不是少写几行 SQL，而是把列名、行范围、计算口径和权限边界集中到一个可管理的数据库对象中。

这一章以 MySQL 8.4 为主，沿用课程中的电商与组织架构表：

• customers(customer_id, customer_name, phone, email, city, registered_at, referrer_id)
• categories(category_id, category_name, parent_id)
• products(product_id, category_id, product_name, unit_price, stock, status, created_at)
• orders(order_id, customer_id, order_date, status, total_amount)
• order_items(order_item_id, order_id, product_id, quantity, unit_price, discount_rate)
• payments(payment_id, order_id, paid_at, amount, payment_method, status)
• departments(department_id, department_name)
• employees(employee_id, department_id, manager_id, employee_name, job_title, salary, hire_date)
• inventory_movements(movement_id, product_id, employee_id, movement_type, quantity, moved_at, note)

示例中出现 PostgreSQL 差异时会明确标出。没有标注的管理语句与查询思路均以 MySQL 为准。

普通视图究竟保存了什么

先看一条很常见的查询：运营同事只关心已完成订单，希望每次都获得相同的一组列。

CREATE VIEW v_completed_orders AS
SELECT
    o.order_id,
    o.customer_id,
    c.customer_name,
    c.city,
    o.order_date,
    o.total_amount
FROM orders AS o
JOIN customers AS c
  ON c.customer_id = o.customer_id
WHERE o.status = '已完成';

CREATE VIEW 并没有把已完成订单复制到另一块永久存储中，也没有在创建那一刻保存查询结果。数据库保存的是视图定义及其相关元数据。以后执行：

SELECT order_id, customer_name, total_amount
FROM v_completed_orders
WHERE city = '杭州'
ORDER BY order_date DESC;

数据库会把“查询视图的条件”和“视图内部的定义”一起交给优化器。底层订单变化后，再查询视图看到的也是新的结果。

杭州当前有两笔已完成订单，查询结果是：

这里有三个容易混淆的对象：

MySQL 的普通视图不是物化视图，也不是结果缓存。PostgreSQL 同样区分普通视图与物化视图：普通视图每次被引用时参与查询处理，物化视图才会持有可刷新的结果。本章只讨论普通视图。

数据更新后，视图为什么马上变了

假设订单 114 从“已完成”改成“已退款”：

START TRANSACTION;
 
UPDATE orders
SET status = '已退款'
WHERE order_id = 114;
 
SELECT order_id, status
FROM orders
WHERE order_id = 114;

再查询 v_completed_orders：

SELECT order_id
FROM v_completed_orders
WHERE order_id = 114;
 
ROLLBACK;

回滚前，视图查询结果为空。不是数据库主动“刷新”了视图，而是下一次查询重新依据 o.status = '已完成' 判断，这一行已经不满足条件。最后的 ROLLBACK 把演示修改撤回，后续示例仍从原始订单状态开始。

视图定义不是一段随意展开的文本

把视图理解为“给 SELECT 起别名”便于入门，但不要由此推断数据库只是做字符串替换。数据库会保存对象依赖、列信息、安全上下文等元数据，并在执行时完成解析、重写与优化。MySQL 还会根据视图定义选择合并或临时表处理方式，后面会专门讨论。

另一个细节是 SELECT *。在 MySQL 中，视图创建时的输出列会被确定下来。之后给底层表新增列，并不会自动把新列加入既有视图；删除或修改被视图依赖的列，反而可能让视图失效。因此，生产视图应明确列出字段：

-- 不推荐：接口范围不够清楚
CREATE VIEW v_customer_all AS
SELECT *
FROM customers;
 
-- 推荐：输出契约一眼可见
CREATE VIEW v_customer_directory AS
SELECT
    customer_id,
    customer_name,
    city,
    registered_at
FROM customers;

创建、修改与删除：把视图当成有版本的接口

一个稳定视图需要同时管好名称、列顺序、列类型、定义和权限。最基本的创建语法是：

CREATE VIEW 视图名 [(视图列名, ...)] AS
SELECT ...;

例如，给客服建立客户目录：

CREATE VIEW v_customer_directory (
    customer_id,
    customer_name,
    city,
    registered_at
) AS
SELECT
    c.customer_id,
    c.customer_name,
    c.city,
    c.registered_at
FROM customers AS c;

显式的视图列清单有两个价值。第一，它让外部列名不必跟随内部表达式；第二，它让列的数量与顺序成为清晰契约。列清单的数量必须与 SELECT 输出表达式数量一致，而且列名不能重复。

也可以直接在查询中取别名：

CREATE VIEW v_product_catalog AS
SELECT
    p.product_id,
    p.product_name,
    p.unit_price AS sale_price,
    p.stock,
    p.status
FROM products AS p;

两种方式都能命名视图列。团队应选一种主要风格并保持一致。对外发布的视图尤其适合显式列清单，因为接口审查时更容易发现列顺序变化。

查看视图的外形与完整定义

DESCRIBE v_product_catalog;

DESCRIBE 适合看输出列，SHOW CREATE VIEW 才适合核对完整定义、安全上下文和算法设置：

SHOW CREATE VIEW v_product_catalog;

执行 SHOW CREATE VIEW 需要相应的 SHOW VIEW 权限以及该视图的查询权限。遇到“能查询但看不到定义”的情况，不要误判为对象损坏，先核对权限。

管理权限也应分开理解：在 MySQL 中，创建视图需要 CREATE VIEW，同时创建者必须对定义中用到的列拥有相应权限；ALTER VIEW 和替换既有视图还需要该视图的 DROP 权限；删除视图同样需要 DROP。因此，“能查询一个视图”并不自然意味着“能看到定义、修改定义或删除它”。生产角色通常只获得业务所需的 SELECT，对象管理交给迁移账号。

修改定义：ALTER VIEW 与 CREATE OR REPLACE VIEW

当商品目录只应暴露在售商品时，可以修改视图：

ALTER VIEW v_product_catalog AS
SELECT
    p.product_id,
    p.product_name,
    p.unit_price AS sale_price,
    p.stock,
    p.status
FROM products AS p
WHERE p.status = '在售';

MySQL 的 ALTER VIEW 要求视图已经存在。部署脚本如果既要支持首次创建，也要支持后续替换，可以写：

CREATE OR REPLACE VIEW v_product_catalog AS
SELECT
    p.product_id,
    p.product_name,
    p.unit_price AS sale_price,
    p.stock,
    p.status
FROM products AS p
WHERE p.status = '在售';

PostgreSQL 也支持 CREATE OR REPLACE VIEW，但替换后的查询必须保留既有输出列的名称、顺序和类型，可以在末尾增加新列，不能随意把已有接口改得面目全非。跨数据库迁移时，不要假设“同名语句”在所有细节上都完全相同。

替换视图前应先检查三件事：

1. 调用者是否依赖旧列名、列顺序或数据类型；
2. 新条件是否会让原本可见的行消失；
3. 视图是否被其他视图、存储程序或报表继续引用。

删除视图

DROP VIEW IF EXISTS v_product_catalog;

IF EXISTS 适合写进可重复执行的迁移脚本。删除普通视图不会删除底层 products 表，也不会删除商品数据，但依赖它的上层对象可能受影响。

MySQL 接受 RESTRICT 和 CASCADE 关键字，却不会按 PostgreSQL 的方式执行依赖级联；PostgreSQL 则会真正检查依赖，RESTRICT 会阻止删除被依赖的视图，CASCADE 会连带删除依赖对象。跨方言脚本必须把这处差异当成风险项，而不是只看语法是否通过。

列、行与权限：视图能挡住什么

假设客服只需要客户编号、姓名、城市和用于核验的手机号后四位。直接给 customers 的查询权限，意味着完整手机号和邮箱也暴露了。更合理的做法是建立一个窄视图：

CREATE VIEW customer_service_vw AS
SELECT
    c.customer_id,
    c.customer_name,
    COALESCE(CONCAT('****', RIGHT(c.phone, 4)), '未提供') AS phone_tail,
    c.city,
    c.registered_at
FROM customers AS c;

查询视图：

SELECT customer_id, customer_name, phone_tail, city
FROM customer_service_vw
WHERE city = '上海'
ORDER BY customer_id;

视图提供了三层边界：

• 列边界：没有把 email 和完整 phone 放进输出列；
• 表达式边界：手机号只暴露计算后的末四位；
• 行边界：可以在定义中加入 WHERE，只开放某些行。

例如，只让华东团队查询杭州与上海的客户：

CREATE VIEW v_east_customers AS
SELECT
    customer_id,
    customer_name,
    city,
    registered_at
FROM customers
WHERE city IN ('杭州', '上海');

但定义视图还不等于建立权限边界。真正的边界来自“撤销基表权限，只授予视图权限”。

REVOKE SELECT ON xiaoman_shop.customers
FROM 'customer_service'@'%';
 
GRANT SELECT ON xiaoman_shop.customer_service_vw
TO 'customer_service'@'%';

如果该账号仍能查询 customers，它完全可以绕过视图。因此，视图负责描述允许看到的形状，GRANT 与 REVOKE 才负责封住绕行路径。

DEFINER 与 INVOKER：用谁的权限访问底层对象

MySQL 视图可以指定安全上下文：

CREATE OR REPLACE
    DEFINER = 'app_view_owner'@'%'
    SQL SECURITY DEFINER
VIEW customer_service_vw AS
SELECT
    customer_id,
    customer_name,
    COALESCE(CONCAT('****', RIGHT(phone, 4)), '未提供') AS phone_tail,
    city,
    registered_at
FROM customers;

SQL SECURITY DEFINER 表示访问底层对象时按定义者的权限检查；调用者只需获得视图需要的权限，不必直接获得基表权限。SQL SECURITY INVOKER 则按调用者权限检查底层访问，它更接近“借用视图结构，但不借用定义者访问能力”。MySQL 默认是 DEFINER，生产环境应显式写出，减少误解。

这并不意味着应把管理员账号永久写进所有视图。更稳妥的做法是使用专门、权限最小化、生命周期稳定的视图所有者。若定义者账号被删除或迁移后不存在，视图可能在调用时因安全上下文异常而失败。

PostgreSQL 默认依据视图所有者访问底层关系；把视图设置为 security_invoker 后，底层权限改为依据调用者检查。若视图承担严格的行隔离，还要评估 security_barrier 和行级安全策略，不能把普通 WHERE 条件想当然地当成完整安全系统。

视图的安全边界不是万能墙

视图适合减少暴露面，却不能替代所有安全措施：

• 不要把敏感原值和脱敏值同时输出；
• 不要让同一角色保留基表直查权限；
• 不要在视图中调用权限或行为不清楚的自定义函数；
• 行级隔离涉及多租户时，还要配合数据库的行级安全能力或可靠的应用授权；
• 视图权限、定义者和依赖对象要纳入定期审计。

封装连接与聚合：统一的业务口径

视图最实用的价值之一，是把容易写错的多表连接与计算集中起来。订单明细金额应按成交单价、数量和折扣率计算：

行金额 = quantity × unit_price × (1 - discount_rate)

如果每张报表都自己连接四张表，有人可能忘记折扣，有人可能误用 products.unit_price 代替订单发生时记录的 order_items.unit_price。一个明细视图可以先统一粒度和口径：

CREATE VIEW v_order_item_details AS
SELECT
    o.order_id,
    o.order_date,
    o.status AS order_status,
    c.customer_id,
    c.customer_name,
    c.city,
    oi.order_item_id,
    p.product_id,
    p.product_name

使用者不再需要记住连接路径：

SELECT
    order_id,
    customer_name,
    product_name,
    quantity,
    unit_price,
    discount_rate,
    line_amount
FROM v_order_item_details
WHERE order_id = 101
ORDER BY order_item_id;

两行合计 118.90，与订单 101 的 orders.total_amount 一致。不过，订单总额还可能包含订单级优惠或运费，不能把“明细折后金额永远等于订单总额”写成数据库规律。视图能够统一一种计算口径，却不会自动证明口径正确；金额规则仍需由业务定义。

聚合视图要先说清“一行代表什么”

管理层想看每个城市的已完成订单数、客户数和成交额：

CREATE VIEW v_city_sales_summary AS
SELECT
    c.city,
    COUNT(DISTINCT c.customer_id) AS customer_count,
    COUNT(o.order_id) AS completed_order_count,
    COALESCE(SUM(o.total_amount), 0) AS completed_amount
FROM customers AS c

这里把订单状态条件写在 ON 中，是为了保留暂时没有已完成订单的城市。如果把它写进 WHERE，LEFT JOIN 产生的空侧行会被过滤，结果就只剩有完成订单的城市。

SELECT
    city,
    customer_count,
    completed_order_count,
    completed_amount
FROM v_city_sales_summary
ORDER BY completed_amount DESC, city
LIMIT 5;

视图名和注释应表达清楚：一行是“一个城市”，金额只统计“已完成订单”。如果名字只叫 v_sales，使用者很容易误把它当成商品级、订单级或全状态销售额。

连接造成的重复，是视图里最隐蔽的口径错误

下面的写法把订单、明细和支付一次性连接后再汇总：

SELECT
    o.order_id,
    SUM(oi.quantity * oi.unit_price) AS item_amount,
    SUM(p.amount) AS paid_amount
FROM orders AS o
JOIN order_items AS oi
  ON oi.order_id = o.order_id
JOIN payments 

若一笔订单有 2 行明细和 2 笔支付，连接后会产生 4 行，明细金额和支付金额都可能被重复累加。视图只是封装查询，并不会修复查询本身。先把最常用的订单摘要固定到“一笔订单一行”：

CREATE VIEW order_summary_vw AS
SELECT
    o.order_id,
    c.customer_name,
    o.order_date,
    o.status AS order_status,
    COUNT(oi.order_item_id) AS item_line_count,
    COALESCE(SUM(oi.quantity), 0) AS item_quantity,

查询前五笔订单：

SELECT
    order_id,
    customer_name,
    order_status,
    item_line_count,
    item_quantity,
    total_amount
FROM order_summary_vw
ORDER BY order_id
LIMIT 5;

这个视图的一行始终对应一笔订单。若还要比较明细金额与成功支付金额，应先让明细、支付各自在子查询中聚合到订单粒度，再与 orders 连接，不能直接把两个一对多关系铺在同一层。

用商品销售视图保留“零销量”

如果从 order_items 出发统计，完全没有明细的商品根本不会出现。product_sales_vw 从完整商品集合出发，并把有效订单状态写入连接条件：

CREATE VIEW product_sales_vw AS
SELECT
    p.product_id,
    p.product_name,
    COALESCE(SUM(
        CASE WHEN o.order_id IS NOT NULL THEN oi.quantity ELSE 0 END
    ), 0) AS sold_quantity,
    COALESCE(ROUND(SUM(
        CASE

查找零销量商品：

SELECT product_id, product_name, sold_quantity, sales_amount
FROM product_sales_vw
WHERE sold_quantity = 0
ORDER BY product_id;

order_summary_vw 和 product_sales_vw 都含聚合，适合作为读接口，不应期待它们自动可更新。

视图不是结果缓存：它省的是重复表达，不一定省计算

看到 v_city_sales_summary 后，一个常见误解是：“聚合已经写进视图，查询时应该直接拿汇总结果，所以会更快。”普通视图没有承诺这件事。它保存查询定义，不持久保存那张汇总表。

SELECT *
FROM v_city_sales_summary
WHERE city = '杭州';

为了回答这条查询，数据库仍需读取相关客户与订单，并执行连接和聚合。优化器可能把外层条件下推，减少参与计算的数据；也可能因为聚合、集合操作或表达式而选择物化中间结果。具体计划要看定义、统计信息、索引和数据库版本，不能仅凭“用了视图”推断。

普通视图与缓存思维的区别

普通视图：保存怎么查
结果缓存：保存某次查到了什么，并判断能否复用
物化视图或汇总表：保存计算后的数据，并承担刷新一致性

如果一张复杂报表每分钟运行几十次，普通视图只能让 SQL 统一，并不能消除重复聚合。此时可考虑：

• 给底层连接键和过滤列建立合适索引；
• 缩小日期范围和返回列；
• 维护汇总表；
• 在支持物化视图的数据库中设计刷新策略；
• 在应用缓存中处理允许短暂过期的数据。

选择后面三种方案时，必须同时回答“多久刷新一次”“失败后如何补偿”“查询允许看到多旧的数据”。速度提升不是免费的，它通常用数据新鲜度和维护复杂度交换而来。

视图中写了 ORDER BY，不代表调用者永远按这个顺序收到结果

关系查询结果本身没有保证顺序。即使某些数据库允许在视图定义中出现 ORDER BY，外层查询、优化器重写和其他操作也可能改变顺序。真正需要稳定排序时，调用者必须在最外层写：

SELECT order_id, order_date, total_amount
FROM v_completed_orders
ORDER BY order_date DESC, order_id DESC;

第二个排序键也很重要：多笔订单日期相同时，仅按日期排序的相对顺序仍不稳定。

可更新视图：什么时候写视图等于写基表

普通视图虽然不存数据，但某些简单视图能够把 INSERT、UPDATE、DELETE 映射到底层表。这种能力的关键问题是：视图中的一行能否明确对应基表中的一行？

下面的视图只来自 customers 一张表，每个输出列都直接对应基表列：

CREATE VIEW v_customer_contact AS
SELECT
    customer_id,
    customer_name,
    phone,
    email,
    city,
    registered_at,
    referrer_id
FROM customers;

通过视图更新城市：

UPDATE v_customer_contact
SET city = '苏州'
WHERE customer_id = 7;

再查基表：

SELECT customer_id, customer_name, city
FROM customers
WHERE customer_id = 7;

这不是“更新了视图里的副本”，而是数据库把修改作用到了 customers。

判断自动可更新性的实用清单

不同数据库细节不同，但以下结构通常会让普通视图变成只读，或者让部分列不可更新：

• SUM、COUNT、AVG 等聚合函数；
• GROUP BY、HAVING；
• DISTINCT；
• UNION、INTERSECT、EXCEPT 等集合操作；
• 窗口函数；
• 让一行无法唯一映射回基表行的连接或去重；
• 由函数、算术或常量生成的派生列。

MySQL 对连接视图存在一些有限的更新能力，但一次修改必须能够明确落到一个基表上，插入限制通常更严格。PostgreSQL 的自动可更新视图要求顶层 FROM 恰好只有一个表或另一个可更新视图，并排除顶层分组、去重、集合操作、窗口计算等结构。不要把一个数据库中偶然成功的复杂更新，当作跨数据库通用保证。

例如，脱敏列是表达式，不能把它当作原手机号修改：

CREATE VIEW v_customer_safe_contact AS
SELECT
    customer_id,
    customer_name,
    CONCAT('****', RIGHT(phone, 4)) AS phone_tail,
    city
FROM customers;
 
UPDATE v_customer_safe_contact
SET phone_tail = '****0000'
WHERE customer_id = 2;

MySQL 会拒绝对派生列的更新，因为 phone_tail 没有一个可以直接接收该值的基表列。city 仍可能是可更新列：

UPDATE v_customer_safe_contact
SET city = '无锡'
WHERE customer_id = 2;

可更新不等于适合更新

一个视图今天能更新，不代表它永远适合作为写接口。以后如果定义中加入 DISTINCT 或聚合，写入能力可能消失；如果上层不知道修改最终落到哪张表，审计和排错也会困难。

适合通过视图更新的场景通常很窄：单表、直接列映射、规则清楚、权限明确。复杂业务写入更适合通过应用服务、存储过程或明确的数据库 API 完成。PostgreSQL 还能用 INSTEAD OF 触发器让复杂视图接受写入，但这已经从“自动映射”进入“自定义写入逻辑”，需要单独设计和测试。

WITH CHECK OPTION：别让写入后的行从入口里消失

下面的视图只显示在售商品：

CREATE VIEW v_active_products AS
SELECT
    product_id,
    category_id,
    product_name,
    unit_price,
    stock,
    status,
    created_at
FROM products
WHERE status = '在售';

它是一个简单单表视图，因此可以更新直接映射的列。问题来了：

UPDATE v_active_products
SET status = '下架'
WHERE product_id = 1;

这条语句可能成功，但更新完成后商品 1 不再满足 status = '在售'，于是它立刻从视图中消失。对使用者来说，就像刚改完一行，那一行便不见了。

如果视图既承担写入口，又要求所有写入后的行仍留在它的可见范围内，应加上 WITH CHECK OPTION：

CREATE OR REPLACE VIEW v_active_products AS
SELECT
    product_id,
    category_id,
    product_name,
    unit_price,
    stock,
    status,
    created_at
FROM products
WHERE status = '在售'
WITH CHECK OPTION;

现在再次执行：

UPDATE v_active_products
SET status = '下架'
WHERE product_id = 1;

数据库会拒绝这次修改，因为新行不再满足视图条件。插入同样受检查：

INSERT INTO v_active_products (
    product_id,
    category_id,
    product_name,
    unit_price,
    stock,
    status,
    created_at
) VALUES (
    9901,
    12,
    '便携支架',
    89.00,
    30,
    '下架',
    CURRENT_TIMESTAMP
);

这行也会被拒绝。CHECK OPTION 检查的是写入后的行能否通过视图的筛选条件，不是替代基表上的 NOT NULL、CHECK、唯一键和外键。上一章的约束仍然是数据完整性的底线。

LOCAL 与 CASCADED 的区别

视图可以建立在另一个视图上：

CREATE VIEW v_stocked_active_products AS
SELECT
    product_id,
    category_id,
    product_name,
    unit_price,
    stock,
    status,
    created_at
FROM products
WHERE status = '在售';
 
CREATE VIEW v_affordable_stocked_products AS
SELECT
    product_id,
    category_id,
    product_name,
    unit_price,
    stock,
    status,
    created_at
FROM

CASCADED 会检查当前视图及其底层视图的条件：写入后既要 stock > 0、unit_price <= 500，也要 status = '在售'。省略关键字时，MySQL 与 PostgreSQL 都把 CASCADED 作为默认行为。

若改成 LOCAL CHECK OPTION，当前视图会检查自己直接定义的条件；底层视图的条件是否继续检查，取决于底层视图本身是否声明了检查选项。多层写视图很容易让人误判，因此写接口应尽量少嵌套，并用失败用例测试每一条边界。

MySQL 的 MERGE、TEMPTABLE 与 UNDEFINED

MySQL 为视图提供了一个方言特有的 ALGORITHM 子句。这里的“算法”不是排序算法，而是告诉数据库如何把视图放进整个查询中处理。

CREATE ALGORITHM = MERGE VIEW v_recent_orders AS
SELECT
    order_id,
    customer_id,
    order_date,
    status,
    total_amount
FROM orders
WHERE order_date >= '2026-01-01';

三种取值可以这样理解：

例如：

SELECT order_id, total_amount
FROM v_recent_orders
WHERE customer_id = 1
  AND total_amount >= 300;

在可合并的情况下，MySQL 可以把视图条件与外层条件放到同一个查询计划中理解：

SELECT order_id, total_amount
FROM orders
WHERE order_date >= '2026-01-01'
  AND customer_id = 1
  AND total_amount >= 300;

这段展开是帮助理解，不代表数据库一定生成完全相同的 SQL 文本。

为什么 MERGE 有时无法采用

聚合、DISTINCT、GROUP BY、HAVING、LIMIT、窗口函数、UNION 等结构会阻止视图直接合并，因为中间结果有自己的语义边界。例如：

CREATE ALGORITHM = MERGE VIEW v_daily_sales AS
SELECT
    order_date,
    COUNT(*) AS order_count,
    SUM(total_amount) AS sales_amount
FROM orders
WHERE status = '已完成'
GROUP BY order_date;

这个定义要求 MERGE，但查询本身含有聚合与分组，MySQL 无法按要求合并时会给出警告并改用未定义算法的处理方式。不要以为写下 MERGE 就能强迫优化器突破语义限制。创建后用 SHOW WARNINGS 与 SHOW CREATE VIEW 核对最终状态：

SHOW WARNINGS;
SHOW CREATE VIEW v_daily_sales;

TEMPTABLE 不是永久缓存

CREATE ALGORITHM = TEMPTABLE VIEW v_daily_sales AS
SELECT
    order_date,
    COUNT(*) AS order_count,
    SUM(total_amount) AS sales_amount
FROM orders
WHERE status = '已完成'
GROUP BY order_date;

TEMPTABLE 表示本次语句执行过程中先形成中间结果。它不会让数据跨查询永久保存，也不会把普通视图变成物化视图。下一次查询仍要重新处理。

它还有两个重要影响：

1. 使用临时表算法的视图不可更新；
2. 外层查询操作的是中间结果，优化空间与索引使用方式可能和合并算法不同。

生成中间结果时，MySQL 读取底层表仍可能使用底层索引；但中间结果一旦形成，外层查询不能再像 MERGE 那样直接把新条件与底层表访问合在一起。两阶段处理有时正是需要的边界，有时却会增加物化成本，所以仍要看完整执行计划。

一般不要为了“听起来更快”就固定成 TEMPTABLE。除非你清楚需要隔离查询阶段或规避特定更新冲突，否则从 UNDEFINED 开始，让优化器选择，再用执行计划验证。

PostgreSQL 怎么办

ALGORITHM = MERGE | TEMPTABLE | UNDEFINED 是 MySQL 扩展，不能原样搬到 PostgreSQL。PostgreSQL 会通过查询重写器与优化器处理普通视图；需要物化结果时应明确选择物化视图或汇总表，而不是寻找同名的 ALGORITHM 子句。

索引与性能：优化视图，最终还是优化底层访问

上一章讲过索引能减少扫描，但普通视图本身没有可直接创建的索引。下面的语句在 MySQL 中不可行：

CREATE INDEX idx_view_city
ON v_completed_orders (city);

应该分析视图最终访问了哪些基表列。例如 v_completed_orders 的常见条件是订单状态、客户城市以及订单日期，连接键是 orders.customer_id = customers.customer_id。可以从实际查询模式出发评估：

CREATE INDEX idx_orders_status_date_customer
ON orders (status, order_date, customer_id);
 
CREATE INDEX idx_customers_city_customer
ON customers (city, customer_id);

这只是候选方案，不是见到视图就照抄的模板。复合索引顺序应依据常用过滤、选择性、排序与连接方式决定；过多索引会增加写入成本。

永远查看调用视图后的完整计划

EXPLAIN FORMAT=TREE
SELECT
    order_id,
    customer_name,
    total_amount
FROM v_completed_orders
WHERE city = '杭州'
  AND order_date >= '2026-07-01';

排查时重点看：

• 是否扫描了远超预期的行；
• 外层 city、order_date 条件是否下推；
• 连接是否利用主键、外键列索引；
• 是否出现临时表、排序或大范围聚合；
• 估算行数与返回行数是否差距很大；
• 视图展开后是否重复访问同一张大表。

执行计划中不一定显示一个名叫“视图扫描”的独立步骤。采用合并方式时，你更可能直接看到底层表；出现物化中间结果时，才会看到派生表或临时结果相关步骤。

为什么给底层表建了索引，视图仍然慢

常见原因包括：

1. 筛选列被函数包裹：例如 DATE(order_date) = '2026-08-01'，可能不利于普通日期索引范围扫描；
2. 聚合前数据量太大：先连接海量明细再分组，索引只能解决部分读取成本；
3. 连接粒度错误：一对多与一对多叠加导致行数爆炸；
4. 外层只取一小部分，内部却因语义边界先算全量；
5. 统计信息过旧：优化器低估或高估行数，选错连接策略；
6. 返回列过宽：读取了大量不需要的文本或表达式；
7. 视图嵌套过深：同一条件在多层出现，依赖难以辨认。

把函数条件改成范围条件是典型改法：

-- 不够利于普通 order_date 索引
WHERE DATE(order_date) = '2026-08-01'
 
-- 边界明确，也更容易形成范围扫描
WHERE order_date >= '2026-08-01'
  AND order_date <  '2026-08-02'

视图套视图：可复用不等于应无限叠加

假设形成了这条依赖链：

v_management_dashboard
  → v_city_sales_summary
    → v_completed_orders
      → orders + customers

每一层单独看都很整洁，但四层合起来可能出现：重复计算、无法下推的条件、隐藏的去重、同一基表多次连接，以及难以定位的列来源。更麻烦的是，修改底层视图的一列，可能让最上层直到运行时才报错。

控制风险的实用原则：

• 对外接口视图可以依赖一层经过审查的基础视图，但避免无限叠加；
• 聚合视图明确粒度，名称带上 detail、daily、summary 等语义；
• 不为了少写五行 SQL 就创建一层新视图；
• 定期查看完整定义与依赖关系；
• 性能排查时把整条依赖链展开，而不是只盯最外层 SQL；
• 修改前先找所有上游调用者，修改后逐层做回归查询。

用 UNION ALL 提供分段数据的统一入口

贯穿课程的核心结构始终只有前文列出的九张表，其中订单事实保存在 orders。这一节额外讨论一种上线后的扩展情形：当数据规模增长，团队可能把 orders 按时间迁移成当前段与归档段。下面的 orders_current、orders_archive 只是为了说明这种迁移后的统一入口，不属于核心九表，也不是完成前后章节的前置条件。

假设扩展出的两张分段表与 orders 保持相同列结构：

orders_current(order_id, customer_id, order_date, status, total_amount)
orders_archive(order_id, customer_id, order_date, status, total_amount)

可以建立统一入口：

CREATE VIEW v_all_orders AS
SELECT
    order_id,
    customer_id,
    order_date,
    status,
    total_amount
FROM orders_archive
 
UNION ALL
 
SELECT
    order_id,
    customer_id,
    order_date,
    status,
    total_amount
FROM orders_current;

调用者只查一个名字：

SELECT
    customer_id,
    COUNT(*) AS order_count,
    SUM(total_amount) AS total_amount
FROM v_all_orders
WHERE order_date >= '2025-01-01'
  AND status = '已完成'
GROUP BY customer_id
ORDER BY total_amount DESC;

这里必须用 UNION ALL，前提是当前区和归档区没有重叠。普通 UNION 会额外去重，不仅增加排序或哈希成本，还可能错误合并两笔恰好所有输出列都相同、但业务上不同的数据。

统一入口真正困难的是迁移边界

假设归档任务先把一笔订单复制到 orders_archive，之后才从 orders_current 删除。两个动作之间，这笔订单同时存在于两张表，视图就会返回两次。反过来，如果先删后插，中间失败，订单会暂时消失。

因此需要明确：

• order_id 在两个分段中全局唯一；
• 归档迁移在事务或可恢复流程中完成；
• 日期边界不重叠，例如当前表保存 2026-05-01 及之后，归档表只保存此前数据；
• 两张表对应列的数据类型、字符集和语义一致；
• 迁移后用重复 ID 与总数校验确认没有重叠或缺口。

检查重复订单：

SELECT
    order_id,
    COUNT(*) AS copies
FROM v_all_orders
GROUP BY order_id
HAVING COUNT(*) > 1;

正常情况下结果应为空。

检查指定边界两侧的数据：

SELECT 'current' AS source_name, MIN(order_date), MAX(order_date)
FROM orders_current
 
UNION ALL
 
SELECT 'archive' AS source_name, MIN(order_date), MAX(order_date)
FROM orders_archive;

手工分表加视图能稳定上层入口，但不保证自动获得数据库原生分区的裁剪能力。外层日期条件能否只访问一个分段，要看优化器、定义和约束信息。对大数据量查询，仍需用执行计划确认。

权限、定义和依赖的排错清单

视图出错时，表面提示经常离根因很远。下面用“症状—检查—处理”的方式整理高频问题。

症状一：视图存在，却提示无权查看定义

先区分“查询视图”和“查看定义”是两种权限：

SELECT *
FROM customer_service_vw
LIMIT 1;
 
SHOW CREATE VIEW customer_service_vw;

前者成功、后者失败时，优先检查 SHOW VIEW，不要急着重建对象。

SHOW GRANTS FOR 'customer_service'@'%';

症状二：视图突然报底层列不存在

底层表改名、删列或改列后，依赖它的视图可能失效。MySQL 不一定在修改基表时阻止你，错误可能到查询视图时才暴露。

CHECK TABLE customer_service_vw;
SHOW CREATE VIEW customer_service_vw;

不要只修最外层视图。先找到最底层失效对象，再逐层恢复列契约。

症状三：定义者不存在或没有底层权限

SHOW CREATE VIEW customer_service_vw;

检查 DEFINER 与 SQL SECURITY。若视图使用定义者权限，定义者账号必须存在，并拥有执行视图定义所需的底层权限。迁移数据库时只导入表和视图、不迁移对应账号，是这类故障的常见原因。

修复时不要顺手把定义者改成超级管理员。创建专用最小权限角色，再用 CREATE OR REPLACE VIEW 或 ALTER VIEW 明确设置安全上下文。

症状四：明明是简单 UPDATE，却提示不可更新

依次检查：

1. 视图是否包含聚合、分组、去重、集合操作、窗口函数或派生列；
2. 是否采用 TEMPTABLE；
3. 更新列是否直接来自唯一可定位的基表列；
4. 写入后是否违反 WITH CHECK OPTION；
5. 基表约束、触发器或权限是否拒绝操作。

可以先查 MySQL 的元数据：

SELECT
    table_schema,
    table_name,
    is_updatable,
    check_option,
    security_type
FROM information_schema.views
WHERE table_schema = 'xiaoman_shop'
  AND table_name = 'v_active_products';

症状五：结果突然翻倍

先暂时移除聚合，查看连接后的原始键：

SELECT
    o.order_id,
    oi.order_item_id,
    p.payment_id
FROM orders AS o
JOIN order_items AS oi
  ON oi.order_id = o.order_id
JOIN payments AS p
  ON p.order_id = o.order_id
WHERE o

订单 101 当前有两条明细和一笔支付，所以连接后是两行；支付金额若在这里直接求和，就会被累计两次。若一笔订单再有两笔支付，结果会扩张成四行。看到重复的 payment_id，就能确认不是 SUM 算错，而是两个一对多关系相乘。应分别聚合明细与支付，再回到订单粒度连接。

症状六：外层加了条件，查询还是扫描很多数据

EXPLAIN FORMAT=TREE
SELECT *
FROM v_city_sales_summary
WHERE city = '杭州';

检查聚合或 UNION ALL 是否形成语义边界、视图是否被临时表处理、底层筛选列是否有合适索引。必要时把关键条件放入更接近基表的位置，或为高频报表建立专门汇总结构。不要通过继续叠加视图来掩盖慢查询。

综合练习：从能查询到可维护

以下练习都沿用本章统一字段。先独立完成，再展开参考答案。

练习一：建立安全的员工名录

创建 v_employee_directory，要求显示员工编号、姓名、职位、部门名称和入职日期，不得暴露薪资；没有部门的员工也要保留。然后只向角色 hr_reader 授予视图查询权限。

CREATE VIEW v_employee_directory AS
SELECT
    e.employee_id,
    e.employee_name,
    e.job_title,
    d.department_name,
    e.hire_date
FROM employees AS e
LEFT JOIN departments AS d
  ON d.department_id = e.department_id;

练习二：统一订单明细金额

创建 v_order_item_amounts，每行对应一个订单明细，输出订单编号、明细编号、商品编号、商品名、数量、成交单价、折扣率和四舍五入到两位小数的行金额。

CREATE VIEW v_order_item_amounts AS
SELECT
    oi.order_id,
    oi.order_item_id,
    oi.product_id,
    p.product_name,
    oi.quantity,
    oi.unit_price,
    oi.discount_rate,
    ROUND(
        oi.quantity * oi.

练习三：限制库存调整入口

创建可更新视图 v_sellable_stock，只显示状态为“在售”且库存大于等于 0 的商品，并用检查选项阻止通过该入口把库存改成负数或把商品改为其他状态。

CREATE VIEW v_sellable_stock AS
SELECT
    product_id,
    category_id,
    product_name,
    unit_price,
    stock,
    status,
    created_at
FROM products
WHERE status = '在售'
  AND stock >= 0
WITH CASCADED CHECK OPTION;
 
UPDATE v_sellable_stock
SET stock = stock - 1
WHERE

练习四：找出订单金额与支付金额不一致的记录

创建一个订单级视图，统计状态为“成功”的支付金额，再找出支付金额与订单总额不同的订单。没有成功支付的订单也要保留。

CREATE VIEW v_order_payment_summary AS
SELECT
    o.order_id,
    o.customer_id,
    o.order_date,
    o.status AS order_status,
    o.total_amount,
    COALESCE(SUM(p.amount), 0) AS paid_amount
FROM orders AS o

练习五：识别不该继续嵌套的视图

团队计划创建 v_city_large_sales，它依赖 v_city_sales_summary，只保留成交额超过 10000 的城市。你需要判断是否值得增加这一层。

SELECT
    city,
    customer_count,
    completed_order_count,
    completed_amount
FROM v_city_sales_summary
WHERE completed_amount > 10000;

练习六：写出上线前检查单

为一个将要发布给报表账号的视图列出至少八项检查。

从稳定入口走向元数据

到这里，视图已经不再只是“保存一条 SELECT”：

• 它用固定列名向上层提供稳定入口；
• 它能封装连接、聚合和统一业务口径；
• 它能配合权限缩小列与行的暴露范围；
• 简单视图可以映射写入，WITH CHECK OPTION 能守住可见条件；
• MySQL 的 MERGE、TEMPTABLE 与 UNDEFINED 会影响处理方式，但不会把普通视图变成结果缓存；
• 视图没有自己的普通索引，性能最终仍取决于完整查询计划与底层表；
• UNION ALL 视图可以统一分段数据，但重叠、缺口和类型一致性必须由设计保证。

当数据库里有几十个视图时，新的问题自然出现：哪些对象是视图，哪些是表？某个视图有哪些列？它是否可更新？使用哪种安全类型？依赖哪些对象？谁拥有它？

这些问题不能靠记忆，也不该靠逐个打开文件寻找。数据库会把对象类型、列、权限、约束、索引和视图定义记录为“关于数据的数据”。下一章，我们就从 information_schema 出发，学习如何查询这些元数据，让数据库自己回答“它现在究竟是什么样子”。

LEFT JOIN 保留没有部门的员工。真正的薪资隔离来自不输出 salary，同时不让该角色直查 employees。

这里使用订单明细中的 unit_price，因为它记录成交时价格；商品表中的价格可能已经变化。

更新语句中的 stock >= 1 避免并发场景下直接减出负数，WITH CHECK OPTION 再保证新行仍符合视图条件。基表仍应有 CHECK (stock >= 0) 之类的约束作为最终防线。

把支付状态条件放在 ON 中，才能保留零成功支付的订单。视图一行对应一笔订单，后续比较不会受订单明细行数影响。