MySQL 视图这个功能，我带的几个新同学几乎都在同一个地方踩过坑：建的时候觉得特别优雅，把一堆 JOIN、过滤条件、字段裁剪全封进视图，业务代码里一句SELECT * FROM v_xxx就收工；等到某天报表突然变慢、某天更新报CHECK OPTION failed、某天做完数据迁移报ERROR 1449，才发现自己对视图在 MySQL 里到底怎么执行、能干什么不能干什么，其实一无所知。视图看着像"保存下来的 SQL"，但它既不是物化表，也不是存储过程，它是优化器在解析阶段就要展开或物化的一层逻辑封装，理解偏差会直接变成线上事故。

这篇东西我按自己的使用习惯来写：先把视图的定位和适用边界说清楚，再把建视图时那几个必须理解的开关（ALGORITHM、DEFINER、SQL SECURITY、WITH CHECK OPTION）拆开讲，然后是视图能不能更新这件事的判定清单、性能上的真实成本、权限隔离场景下的用法，最后是我这些年攒下来的排查表和几条实打实的心得。不管你是刚接触 MySQL 视图，还是已经在项目里用了一堆视图但心里没底，应该都能从里面抄到能直接落地的东西。

1. 我为什么会在项目里主动用视图

1.1 先把定义说人话：视图不是表，是一段被命名的 SELECT

MySQL 里的视图（View）本质上是数据库里保存下来的一条 SELECT 语句，加上一个名字。你查视图的时候，MySQL 并不是去读一张真实存在的表，而是把这条 SELECT 拿出来，按某种方式和你的外层查询结合，最终还是要落到基表上去取数据。所以视图本身不占数据页、不存行、不能单独建索引，SHOW TABLE STATUS里也看不到它的数据量。

这个"虚拟"属性决定了它的两个基本面。好处是：基表数据一变，视图查出来立刻就是新的，不存在同步延迟、不存在刷新任务、不会像物化表那样需要定时跑批。坏处是：视图没有自己的统计信息，优化器只能看基表的统计信息，一旦视图里封装的东西太复杂，执行计划就可能跑偏，而你在业务代码里完全看不出来。

我一般会把视图理解成"数据库层的 API"：对上层暴露一组稳定的列名和语义，把底下的表结构变化、多表 JOIN、过滤条件挡在视图内部。这个类比很贴切——API 改版本要考虑兼容，视图改定义也要考虑调用方；API 背后可能是多个微服务，视图背后可能是多张表。

1.2 我真正会用视图的几个场景

说几个我自己项目里确实用了视图、并且事后觉得用对了的地方。

第一个是报表和 BI 层对接。某数据分析项目要给 BI 工具开一个只读账号，BI 那边的人不懂我们的表结构，也不该懂。我们的做法是给每个主题域建一个视图，把事实表和维度表的 JOIN、软删除过滤（is_deleted = 0）、状态枚举翻译全封进去，BI 只管SELECT视图。后面我们底层做了分表、改了字段名、把枚举从数字换成字符串，只要视图定义跟着改，BI 那边的报表一张都不用动。这个收益非常实在。

第二个是权限收敛。MySQL 的权限粒度是库级、表级、列级，列级权限配起来麻烦而且容易漏，行级权限干脆没有。用视图可以做到"只给视图权限、不给基表权限"——基表里有一堆敏感字段（手机号、身份证、成本价），视图里只暴露脱敏后的或者干脆不暴露，业务账号只有视图的SELECT权限。这个配合SQL SECURITY DEFINER用起来很顺，后面第 5 章细讲。

第三个是统一口径。比如"有效订单"这个定义，在不同代码里被重复写了七八遍，每处的条件还略有出入（有的漏了status != 9，有的漏了时间范围）。这种口径漂移在财务对账时是灾难。我们的处理是把口径固化成一个视图，所有人查"有效订单"都从视图走，口径只有一份，改也只改一处。

第四个是多租户或者多环境的数据隔离。共享表结构、按tenant_id隔离的系统，可以给每个租户建一个带固定tenant_id条件的视图，应用连接串里配不同的默认库或者用不同账号，天然就把数据圈住了。当然这个方案在租户数量大的时候不现实（几百个视图维护成本高），我一般只在小租户量或者内部多环境隔离时用。

1.3 什么情况下我坚决不上视图

有几种情况我看到就会拦下来。

一是拿视图当性能优化手段。经常有人问"我给这个复杂查询建个视图是不是就快了"，答案是几乎不会。视图不带索引、不带缓存，MERGE 算法下它就是文本替换，TEMPTABLE 算法下它甚至更慢（多了一次物化）。真要加速，该建索引建索引，该建汇总表建汇总表，该上缓存上缓存。

二是视图层层嵌套。我见过一个项目里视图套视图套了四层，最外层查一次，EXPLAIN出来一坨<derived2>、<derived3>，排查问题时根本不知道该看哪张基表。我的原则是嵌套不超过两层，超过两层就该考虑用一张宽表或者干脆把 SQL 放应用层。

三是需要传参数的场景。MySQL 视图不支持参数，你不能写v_orders(start_date, end_date)。有人试图用会话变量绕（在视图里引用@start_date），这个做法在连接池环境下极其危险——会话变量是连接级的，连接被复用后残留的值会污染下一个人。这种需求老老实实在应用层拼条件，或者封装成存储过程。

四是对实时性要求极高且查询极重的场景。视图每次查都要重新展开执行，没有预计算。如果这个查询本身就是 3 秒级别，那封成视图还是 3 秒，甚至因为优化器选择变差变成 5 秒。

2. 建视图的语法细节与四个必须搞懂的开关

2.1 最小可用写法和完整语法对照

最简写法谁都会：

CREATE VIEW v_orders_paid AS SELECT id, user_id, amount, created_at FROM orders WHERE status = 1;

但生产环境我基本不会这么写，完整语法长这样：

CREATE [OR REPLACE] [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}] [DEFINER = 'user'@'host'] [SQL SECURITY {DEFINER | INVOKER}] VIEW view_name [(column_list)] AS select_statement [WITH [CASCADED | LOCAL] CHECK OPTION];

这几个方括号里的东西，才是决定视图行为的真正开关。OR REPLACE值得单独提一句：修改视图要么ALTER VIEW，要么CREATE OR REPLACE VIEW，后者更方便，因为不需要先 DROP。但要注意，OR REPLACE如果视图不存在会直接创建，如果存在会整体替换定义，列的顺序和名字都可能变，依赖这个视图的上层查询有断裂风险，生产上改视图定义前最好先备份SHOW CREATE VIEW的结果。

另外提醒一个容易被忽略的点：视图和表共用同一个命名空间。也就是说db里已经有一张叫orders的表，你就不能建一个叫orders的视图，会报ERROR 1050 Table 'orders' already exists。这个规则在迁移的时候坑过我们一次——从旧库导出的视图定义在新库里跟表重名了。

2.2 ALGORITHM 的 MERGE 和 TEMPTABLE，差别到底在哪

这是视图里最重要、也最容易被忽略的一个参数，务必搞懂。

ALGORITHM = MERGE的意思是：查询视图时，MySQL 把视图定义的 SQL 和外层的查询语句做"合并"，相当于把你的外层 WHERE、JOIN 条件直接塞进视图定义里，最后变成一个针对基表的完整查询。这个过程有点像 C 语言的宏展开。好处是外层的过滤条件能下推到基表，基表索引照常能用，执行计划里甚至看不出视图的存在。

ALGORITHM = TEMPTABLE的意思是：先把视图定义查出来，结果放进一张内部临时表，然后再在临时表上执行外层的查询。这就惨了——临时表上没有索引（除非 MySQL 自动生成的内部索引），外层的 WHERE 只能在物化完之后过滤，扫描量可能翻好几倍。

ALGORITHM = UNDEFINED是默认值，含义是"让服务器自己选"，服务器会优先选 MERGE，只有在 MERGE 不可行的时候才退化成 TEMPTABLE。哪些情况 MERGE 不可行？常见的包括：视图定义里有聚合函数（SUM、COUNT、MAX等）、有DISTINCT、有GROUP BY、有HAVING、有UNION或UNION ALL、SELECT 列表里有子查询、有窗口函数。这些一出现，不管你写没写ALGORITHM = MERGE，都会自动走 TEMPTABLE。

我做了个对照表，方便你判断：

我的建议很直接：视图定义尽量保持简单，能在应用层做的聚合就别塞进视图。如果确实需要聚合，那就在注释里明确写清楚"本视图为 TEMPTABLE，勿在大表上高频查询"，避免后面接手的人踩雷。

2.3 DEFINER 和 SQL SECURITY：权限模型的关键组合

这两个参数是绑在一起理解的。

DEFINER指定这个视图"以谁的身份"存在，默认是你创建它时的当前用户。SQL SECURITY有两个取值：

• SQL SECURITY DEFINER（默认）：查询视图时，用定义者的权限去访问基表。也就是说，调用者只要有视图的SELECT权限就够了，不需要基表权限。
• SQL SECURITY INVOKER：查询视图时，用调用者的权限去访问基表。调用者必须同时拥有视图权限和基表权限。

这两个选项直接决定了你的权限设计能不能成立。想做"只给视图、不给基表"的隔离，必须用DEFINER；想避免定义者权限被滥用（比如视图绕过权限管控查到不该看的数据），用INVOKER更保守。

我自己的选择习惯：面向业务应用的脱敏视图、报表视图用DEFINER，并且专门建一个权限收敛过的账号作为定义者；面向 DBA 或内部工具、需要严格审计的场景用INVOKER。

这里有个必须记住的坑：DEFINER那个账号如果被删掉或者改了 host，视图立刻失效，查询会报ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist。这个错误在做完账号清理、或者从测试库导数据到生产库之后特别常见，因为mysqldump导出的视图定义里带着原始的DEFINER。我的处理办法是备份脚本里统一做一次DEFINER剥离，或者干脆在恢复后用脚本批量ALTER VIEW ... DEFINER=...修正。

2.4 WITH CHECK OPTION：防止数据"越界"的约束

这个选项只有在视图可更新的时候才有意义，作用是：通过视图做INSERT或UPDATE时，检查新数据是否满足视图定义里的WHERE条件，不满足就报错拒绝。

举个例子，视图只包含status = 1的订单：

CREATE OR REPLACE VIEW v_orders_paid AS SELECT id, user_id, amount, status, created_at FROM orders WHERE status = 1 WITH CHECK OPTION;

那么INSERT INTO v_orders_paid (user_id, amount, status) VALUES (1001, 99.00, 0)会直接报ERROR 1369 (HY000): CHECK OPTION failed 'demo.v_orders_paid'。没有这个选项的话，这条 INSERT 是能成功的——数据插进去了，但你在视图里看不到它，这就是所谓的"幽灵行"。

它还有两个修饰词：

• WITH CASCADED CHECK OPTION（默认）：检查本视图和所有底层视图的条件。
• WITH LOCAL CHECK OPTION：只检查本视图自己的条件，不检查底层视图。

视图嵌套的时候这两个有区别，但如果你的视图不嵌套（我建议不嵌套），直接用默认的CASCADED就行。

需要说明的是，WITH CHECK OPTION只对INSERT和UPDATE生效，DELETE不需要检查。另外如果视图本身不可更新，加了这个选项也不会报错，只是不起作用——这个"静默失效"挺坑的，所以一定要确认视图是IS_UPDATABLE = YES。

3. 视图能不能更新，判断标准与实测清单

3.1 判断可更新性的硬性条件

视图可更新（updatable）意味着你能对视图做INSERT、UPDATE、DELETE，MySQL 会把操作映射到基表上。这个映射不是随便就能做的，必须满足"视图里的每一行都能唯一对应到基表的一行"。

MySQL 官方给的判定条件我整理成了一张清单，任何一条不满足就不可更新：

最靠谱的做法不是背清单，而是直接查：

SELECT TABLE_NAME, IS_UPDATABLE, SECURITY_TYPE, DEFINER, CHECK_OPTION FROM information_schema.VIEWS WHERE TABLE_SCHEMA = 'demo';

IS_UPDATABLE是YES就说明可以写。这个字段比任何文档都准，因为它反映的是当前版本、当前定义下的真实判定结果。

3.2 实测：这些写法会让视图悄悄变成只读

我在测试库里做过一轮实测，把常见写法都试了一遍。环境是 MySQL 8.0，表结构如下：

CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, tenant_id INT NOT NULL, user_id BIGINT NOT NULL, amount DECIMAL(12,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_tenant_status (tenant_id, status) );

测下来几个结论值得记下来。

加了DISTINCT的视图，IS_UPDATABLE直接变NO，UPDATE报ERROR 1288 (HY000): The target table v_xxx of the UPDATE is not updatable。这个很好理解，但很多人是在报错之后才想起来视图里有DISTINCT。

SELECT *建出来的视图，可更新性没问题，但要注意*在创建那一刻就被展开成当时完整的列清单了，基表后来加的列不会出现在视图里。这个特性很多人误解，以为视图里的*是动态的。所以基表加列之后，如果这个新列需要出现在视图里，必须重建视图。

带LIMIT的视图，实测IS_UPDATABLE是NO。如果你就是想"只允许改前 N 条"，那得换思路，用带条件的视图配合有序主键筛选。

单表视图里 SELECT 列表包含表达式，比如amount * 100 AS amount_cent，整个视图就不可更新了——因为amount_cent无法反推回基表的amount（有精度损失）。但如果你把它写成amount和amount * 100 AS amount_cent两列并存，视图仍然是可更新的，只是你UPDATE的时候不能去写那个计算列。

3.3 通过视图更新时，那些容易翻车的细节

可更新不代表怎么更都行，有几个细节要清楚。

第一，INSERT进视图时，视图里没暴露的列会取默认值。如果基表里某个 NOT NULL 列既没有默认值、又不在视图列里，INSERT会报ERROR 1364 (HY000): Field 'xxx' doesn't have a default value。所以设计可写视图时，要么把必填列都暴露出来，要么给基表列配上合理的默认值。我个人倾向后者，顺带也能让直接写基表的代码少踩雷。

第二，UPDATE通过视图改主键是允许的，但行为要小心。它会真的去改基表的主键值，如果有外键引用，可能直接报约束错误，也可能级联改掉一片数据。生产上我的习惯是视图里暴露主键列（方便定位），但业务代码禁止通过视图改主键。

第三，WITH CHECK OPTION的检查发生在写入前，是行级的。批量INSERT ... SELECT时只要有一行不满足条件，整条语句就失败（在非事务表上可能有部分写入，但 InnoDB 是原子的）。这一点对数据导入脚本影响较大，建议在导入前先用SELECT校验一遍数据。

第四，通过视图UPDATE时如果触发了基表的ON UPDATE CURRENT_TIMESTAMP，时间列照常更新，这个没问题。但如果视图里包含LIMIT（不可更新的情况），连语句都执行不了，不用考虑这些。

4. 性能成本：视图到底贵在哪

4.1 MERGE 算法下的执行计划对照

MERGE 视图本质是文本展开，性能应该和直接写 SQL 一样。我做过一组对照，用 50 万行的订单表，查询某个租户近 30 天的已支付订单：

-- 直接查基表 EXPLAIN SELECT id, amount FROM orders WHERE tenant_id = 10 AND status = 1 AND created_at >= '2024-05-01'; -- 通过 MERGE 视图查 CREATE ALGORITHM=MERGE VIEW v_orders_paid AS SELECT id, tenant_id, user_id, amount, status, created_at FROM orders WHERE status = 1; EXPLAIN SELECT id, amount FROM v_orders_paid WHERE tenant_id = 10 AND created_at >= '2024-05-01';

两条EXPLAIN的输出几乎完全一致，都是走idx_tenant_status，rows估算值也一样，Extra里都是Using index condition。这就是 MERGE 该有的表现——优化器把视图里的status = 1和外层的tenant_id = 10合并成一个复合条件，正好命中联合索引。

这里顺带说一个实战技巧：如果你怀疑某个视图导致了执行计划异常，可以用优化器开关快速验证是不是派生表合并的问题：

SET SESSION optimizer_switch = 'derived_merge=off'; -- 跑你的查询，看执行计划和耗时变化 SET SESSION optimizer_switch = 'derived_merge=on';

如果关掉之后反而变快，说明合并后的计划选择有问题，这时候要考虑重写视图或者加索引提示。这个开关只影响当前会话，改完记得切回来。

4.2 TEMPTABLE 和聚合带来的物化代价

一旦视图里出现聚合、GROUP BY、DISTINCT、UNION，算法自动切到 TEMPTABLE，代价就上来了。EXPLAIN里会看到select_type是PRIMARY加上一个DERIVED行，DERIVED那行就是物化视图结果的那一步。

物化的成本主要体现在三块：一是要把视图定义的结果完整算出来，这个中间结果可能比最终需要的行数大很多；二是临时表要写进内存或者磁盘，tmp_table_size不够就会落盘，那就更慢；三是外层过滤没法下推，只能物化完再筛。

我遇到过一个典型场景：某报表视图里带了COUNT(DISTINCT user_id)做去重统计，外层再按日期过滤。因为是 TEMPTABLE，MySQL 先把全表按视图定义聚合一遍，再筛日期——等于每天点一次报表就把几千万行扫了一遍。后来改成把日期条件下沉到视图里的WHERE（虽然视图不能传参，但可以在应用层维护几个按月份切分的视图，或者干脆不用视图直接拼 SQL），耗时从 40 多秒降到 1 秒以内。

4.3 两个真实的慢查询改造记录

第一个案例来自一个内部管理系统。A 同学为了"代码整洁"，把订单、订单明细、商品三张表的 JOIN 封成了一个视图v_order_detail，业务代码里到处SELECT ... FROM v_order_detail WHERE order_id = ?。单看语句没问题，但视图是 MERGE 的三表 JOIN，order_id是订单表主键，理论上很快。问题出在他还在视图里加了个LEFT JOIN用户表取昵称，而这个 JOIN 没有索引支撑，导致每次查询都要扫一遍用户表。优化方案不是改视图算法，而是把用户昵称这个字段从视图里拿掉，需要的时候单独查或者用冗余字段。这就是典型的"视图暴露了不该暴露的 JOIN"。

第二个案例是多层嵌套。某跨模块查询用了v_a，v_a基于v_b，v_b基于v_c，每一层都加了点过滤条件。三层叠下来，EXPLAIN里有三个DERIVED，而且中间层因为带了UNION全部走 TEMPTABLE，最终查询 12 秒。改造方式很土：把三层的逻辑拍平成一个视图，UNION部分改用UNION ALL加去重标记，最后降到 800 毫秒。教训是：视图嵌套的每一层都要单独验证性能，别指望优化器能穿透三层给你优化。

5. 权限隔离与多租户场景的落地姿势

5.1 用视图做列级和行级隔离

MySQL 原生支持列级权限（GRANT SELECT(col1, col2) ON db.t TO user），但配起来繁琐，而且列名改了权限不会跟着变。用视图做隔离更直观：

CREATE ALGORITHM=MERGE DEFINER='app_definer'@'%' SQL SECURITY DEFINER VIEW v_user_public AS SELECT id, nickname, avatar_url, CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) AS phone_masked FROM users WHERE is_deleted = 0; GRANT SELECT ON demo.v_user_public TO 'app_readonly'@'%';

注意这里我特意没给app_readonly任何基表权限，它只能通过视图看数据。DEFINER指向一个有基表权限的专用账号，SQL SECURITY DEFINER让视图以那个账号的权限执行。这样即使有人拿到了app_readonly的密码，也只能看到脱敏后的字段，而且看不到已删除的数据。

行级隔离同理，把固定条件写进视图就行。多环境场景下我经常这么干：给测试库建一个只包含测试租户数据的视图，测试同学随便查，不会误看到生产数据。

注意：DEFINER账号的密码策略、过期时间要单独管理，一旦这个账号被锁或者密码过期，所有依赖它的视图全部不可用。我一般会把它设成一个不允许登录的账号（ACCOUNT LOCK），只作为权限载体存在。

5.2 DEFINER 权限模型的三个风险点

用DEFINER提权很方便，但风险也要清楚。

第一个风险是权限放大。定义者账号的权限有多大，通过视图就能触达多大。如果定义者是个DBA级别账号，那这个视图相当于给调用者开了一个 DBA 后门。原则是：定义者只授予视图需要的基表SELECT（必要时加INSERT/UPDATE），绝不给多余权限。

第二个风险是定义者被删除导致视图失效，前面提过，ERROR 1449。运维层面要有巡检，定期对比information_schema.VIEWS.DEFINER和mysql.user的差集。

第三个风险是DEFINER加上SQL SECURITY DEFINER之后，审计日志里记录的执行用户是定义者，不是真实调用者，排查问题时容易误判。如果审计要求高，这条路就走不通，得用INVOKER加基表授权的方案。

5.3 备份、迁移和 DDL 变更时视图的坑

mysqldump导出的视图定义里带DEFINER和完整的CREATE ALGORITHM=... VIEW语句，而且视图默认是最后才导出（因为要依赖基表）。跨环境恢复时最常见的三个问题：

一是DEFINER账号不存在，恢复过程报错或者恢复后查询报 1449。处理办法是导出时加--no-data之外，恢复前先建好统一的定义者账号，或者用一个 sed 脚本把DEFINER=...段剥掉。

二是恢复顺序问题。如果只导出了部分表，视图依赖的某张表没恢复，CREATE VIEW会直接失败。这时候要么跳过视图相关语句，要么先把依赖表补齐。

三是改基表结构导致视图失效。给基表删一列、改列名、改类型，如果这一列被视图引用了，视图不会自动更新，查询时报ERROR 1356 (HY000): View 'demo.v_xxx' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them。这个错误信息很笼统，把"依赖失效"和"权限不足"混在一起，排查时容易走弯路。我的经验是：看到 1356 先查视图依赖的表和列是否还存在，再查DEFINER账号是否有权限，两个方向各查一遍。

6. 日常运维与排查速查

6.1 视图相关的元数据该查哪几张表

日常排查我用得最多的三条查询，直接给出来：

-- 1. 查某个库里所有视图的基本信息 SELECT TABLE_NAME, IS_UPDATABLE, SECURITY_TYPE, DEFINER, CHECK_OPTION FROM information_schema.VIEWS WHERE TABLE_SCHEMA = 'demo' ORDER BY TABLE_NAME; -- 2. 看完整定义 SHOW CREATE VIEW demo.v_orders_paid\G -- 3. 找哪些视图引用了某张表（模糊匹配，精度有限但够用） SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.VIEWS WHERE VIEW_DEFINITION LIKE '%`orders`%';

第三条要说明一下，MySQL 没有原生的视图依赖视图（8.0 也没有像 PostgreSQL 那样的依赖系统表），只能靠文本匹配。VIEW_DEFINITION里表名是被反引号包住的，所以用`orders`匹配相对准确，但如果你的库里有大量视图，这个查询会很慢，别在业务高峰跑。

另外information_schema.VIEWS里的VIEW_DEFINITION是规范化后的文本，跟你原始的CREATE VIEW语句不完全一样（大小写、反引号、OR REPLACE都会被处理），别拿它做字符串比对。

6.2 常见报错速查表

这张表我基本上是照着线上工单整理的，1288 和 1356 出现频率最高，1449 大多发生在环境迁移之后。

6.3 我踩过之后的几条实操心得

用视图这些年，有几个经验是文档里不会写、但确实能省事的。

第一，视图定义里绝对不要用SELECT *，哪怕你觉得现在方便。原因前面说过，*在创建时就展开成静态列清单了，基表加列不会同步，而且视图里的列顺序被锁死，以后加列只能重建视图，重建的时候还要考虑依赖方。老老实实把列名一个个写出来，多打几十个字，换来的是一份可维护的定义。

第二，给视图命名加前缀v_，并且在注释里写清楚用途、口径、是否可更新、算法类型。MySQL 的视图支持COMMENT吗？CREATE VIEW语法里没有COMMENT子句，这是它比表定义弱的地方。所以我把这些信息写在团队内部的表结构文档里，或者在视图名里体现，比如v_orders_paid_merge、v_report_daily_tmp。听起来土，但在几十个视图的库里找东西时非常好用。

第三，新建视图后必须跑一次EXPLAIN加一次真实查询，确认两点：select_type里有没有DERIVED（有就说明走 TEMPTABLE 了），以及rows估算是否合理。我见过太多人建完视图就丢给业务用，出问题才回头查。

第四，视图定义的变更要走跟表结构变更一样的流程：记录变更、评估影响、通知调用方。视图是弱引用，数据库不会阻止你改，也不会告诉你谁在用。我一般的做法是改之前在information_schema.VIEWS里搜一遍有没有别的视图引用它（虽然只能模糊匹配），再在代码仓库里全局搜一遍视图名。

第五，慎用OR REPLACE做"小改动"。它整体替换定义，如果新定义里少写了一列，而调用方SELECT了那一列，报错是ERROR 1054 (42S22): Unknown column，看起来像表结构问题，实际是视图被改了。我的习惯是改视图前先SHOW CREATE VIEW存一份到版本库，出问题时能立刻对比。

第六，还是那句话，别把视图当优化手段。慢查询的根因 99% 是索引缺失、数据量膨胀或者 SQL 写法问题，视图既不会让查询变快，还可能因为 TEMPTABLE 让它变慢。看到有人想用视图"优化"性能，先让他把EXPLAIN拉出来看看。