MySQL中视图是虚拟表，仅保存SELECT定义而不存储数据；表是物理对象，直接在磁盘持久化数据。视图默认只读，更新需满足单表、无聚合等条件；表支持完整DML操作。
MySQL 中的视图和表根本不是同一类东西：表是真实存数据的“仓库”，而视图只是透过窗口看仓库的“取景框”——它本身不存数据，只存一条 SELECT 语句。
本质与存储方式不同
表是物理对象，创建后会在磁盘上分配空间，数据以行和列形式持久保存。插入、更新、删除都直接作用于磁盘文件。
视图是虚拟表，数据库里只保存它的定义（即 CREATE VIEW 后面的 SELECT 语句），不占实际存储空间。每次查询视图，MySQL 都会实时执行那条 SELECT，从基表中动态拉取最新结果。
操作权限差异明显
表支持完整的 DML 操作：
• 可直接 INSERT 新记录
• 可 UPDATE 某些字段
• 可 DELETE 指定行
视图默认只读，能否修改取决于定义是否满足可更新条件：
• 必须只基于单个基表（简单 JOIN 在某些情况下允许）
• 不能含 GROUP BY、DISTINCT、聚合函数（如 SUM、COUNT）
• 不能有子查询（在 SELECT 列表或 WHERE 中）
• 所有列需明确来自基表，不能是表达式或常量
不满足时执行 UPDATE 或 INSERT 会报错。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
用途和设计目标不一样
表承载原始业务数据，是数据建模和事务处理的基础。
视图主要用于：
• 简化复杂查询：比如把多表 JOIN + 条件过滤封装成一个名字，应用层直接查 view_sales_summary
• 控制数据访问：给财务人员建视图，只暴露 salary 字段以外的员工信息，敏感列天然隔离
• 提供逻辑一致性：底层表改名或拆分后，只要视图定义同步调整，上层 SQL 不用动
• 实现行级/列级权限控制：配合 GRANT，让不同角色看到不同“切片”
生命周期与依赖关系独立
删掉一个视图，不会影响它依赖的任何基表，基表数据完好无损。
反过来，如果删了基表，所有依赖它的视图会变成无效状态，后续查询报错“view references invalid table”。
视图可以嵌套（基于其他视图创建），但过度嵌套会影响可读性和性能，一般不建议超过两层。
