SQLite视图（VIEW）本质上是一个被保存下来的SELECT查询。它不存储实际数据，每次访问视图时都会重新执行底层的SELECT语句，因此视图也被称为虚拟表。创建视图的核心语法并不复杂，但使用限制却比很多人想象中要多，尤其是可更新视图的判断规则，需要结合底层查询的结构来理解。
视图的创建语法与基本示例
在SQLite中创建视图使用CREATE VIEW语句，基本格式为CREATE VIEW 视图名 AS SELECT语句。视图名称不能与已有的表或视图重名，而且SQLite不允许使用CREATE OR REPLACE VIEW直接替换已有视图，如果要修改视图定义，必须先DROP VIEW再重新创建。下面用一个简单的员工表来演示：
-- 创建员工表
CREATE TABLE employees (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL,
department TEXT,
salary REAL
);
-- 插入测试数据
INSERT INTO employees (name, department, salary) VALUES
('张三', '技术部', 8000),
('李四', '销售部', 6500),
('王五', '技术部', 9200),
('赵六', '人事部', 5800);
-- 创建只包含技术部员工的视图
CREATE VIEW tech_employees AS
SELECT id, name, salary
FROM employees
WHERE department = '技术部';
创建成功后，直接像查询普通表一样使用SELECT * FROM tech_employees;就能得到技术部员工的数据。视图的字段名默认继承SELECT列表中的列名，也可以通过CREATE VIEW v(column1, column2) AS ...的方式显式指定字段名。如果SELECT中使用了表达式、聚合函数或者列名有歧义，建议显式命名。
视图支持嵌套，即一个视图可以基于另一个视图创建。例如先创建high_salary_employees表示工资大于7000的员工，再基于它创建技术部高薪员工视图。不过每多一层嵌套，查询时的解析和优化成本就会增加，SQLite的查询计划器会尽量把视图展开成底层表，但太深的嵌套仍然会影响可读性和维护性。
视图的更新限制与只读视图判定
并不是所有视图都能执行UPDATE、DELETE或INSERT操作。SQLite规定，只有当视图满足一系列严格条件时，才被视为可更新视图。最核心的判定标准是：视图的SELECT语句必须是从单个表（或单个可更新视图）中直接选取列，不能包含聚合函数、DISTINCT、GROUP BY、HAVING、UNION、JOIN、子查询等结构。此外，SELECT列表中的每一列都必须是底层表的实际列，而不是表达式或常量。
上面创建的tech_employees视图满足条件，因此可以执行更新。例如把技术部员工的工资统一增加500：
-- 更新视图中的数据，实际会修改底层employees表 UPDATE tech_employees SET salary = salary + 500 WHERE id = 1;
但如果我们创建一个包含聚合信息的视图，例如每个部门的平均工资，这个视图就是只读的：
CREATE VIEW dept_avg_salary AS SELECT department, AVG(salary) AS avg_salary FROM employees GROUP BY department;
尝试对这个视图执行UPDATE dept_avg_salary SET avg_salary = 10000;会报错“cannot modify dept_avg_salary because it is a view”。同样，包含DISTINCT的视图也不可更新，因为DISTINCT去重后无法一一对应到底层表的行。多表连接视图通常也不可更新，除非SQLite能明确判定修改只影响其中一个表的列。
SQLite还支持一种特殊的INSTEAD OF触发器，可以附加到视图上，在尝试对视图执行INSERT、UPDATE或DELETE时触发自定义逻辑。这为只读视图提供了一种间接修改数据的方案，但触发器内部的逻辑需要自己保证数据一致性，复杂度较高。
临时视图与视图中的ORDER BY和LIMIT
SQLite允许创建临时视图，语法为CREATE TEMP VIEW 视图名 AS SELECT ...。临时视图只对当前数据库连接可见，连接关闭后自动删除，不会持久化到数据库文件中。临时视图经常在复杂的报表查询或数据迁移脚本中使用，因为不污染全局命名空间。
-- 创建临时视图保存中间结果
CREATE TEMP VIEW tmp_active_users AS
SELECT user_id, login_time
FROM user_log
WHERE login_time >= datetime('now', '-7 days');
-- 基于临时视图做进一步统计
SELECT COUNT(*) FROM tmp_active_users;
一个容易忽略的限制是：视图定义中的ORDER BY子句。SQLite官方文档明确指出，如果视图的SELECT语句包含ORDER BY，那么当外部查询没有自己的ORDER BY时，视图的结果可能会按照该顺序返回，但这并不是强保证。更常见的情况是视图内的ORDER BY会被外层查询覆盖或忽略。因此如果需要稳定的排序，应该在最终查询中显式添加ORDER BY。
类似地，视图中的LIMIT和OFFSET子句只对视图本身生效，当外部查询访问视图时，如果外层也带有LIMIT，会先应用视图的LIMIT再应用外层的LIMIT，行为有时不符合直觉。例如视图只返回前10条，外层查询再取前5条，结果只会取到视图的前5条。为了避免混淆，建议不要在视图定义中放置LIMIT，而是留到使用视图的查询里去控制。
此外，视图一旦创建，其依赖的表结构不能随意修改。例如tech_employees视图依赖employees表的id、name、salary列，如果执行ALTER TABLE employees DROP COLUMN name（SQLite 3.35及以上支持DROP COLUMN），则视图会失效，后续查询会报错“no such column: name”。因此在修改表结构前，需要检查是否有视图依赖这些列，必要时先调整视图定义。
视图的性能特点与使用建议
虽然视图提供了逻辑封装，但它本身不存储数据，所以查询视图的性能完全取决于底层SELECT语句的执行效率。SQLite的查询优化器会尝试下推谓词、合并视图到主查询中，但并非所有情况下都能完美优化。特别是对于包含GROUP BY、DISTINCT的复杂视图，每次外层查询都可能重新计算整个聚合，即使外层只需要聚合结果中的一小部分。
-- 视图内部有聚合，外层再过滤时可能无法利用索引 CREATE VIEW dept_stats AS SELECT department, COUNT(*) AS cnt, SUM(salary) AS total FROM employees GROUP BY department; -- 如果只需要技术部的统计，SQLite仍然会先计算所有部门的聚合 SELECT * FROM dept_stats WHERE department = '技术部';
对于这种场景，更好的做法是把过滤条件下推到视图内部的查询中，或者干脆不使用视图，直接编写带WHERE条件的聚合查询。SQLite的新版本中提供了物化视图的替代方案，即使用普通表存储计算结果，并通过触发器维护数据同步，但这已经超出了本文的范围。
另外，视图不能创建索引。虽然可以基于视图创建触发器，但无法在视图列上创建索引来加速查询。如果某个视图被频繁访问且底层查询较慢，可以考虑将其结果缓存到一张真实表中，定期刷新。
综合来看，SQLite视图最合适的用途是：简化重复的复杂查询、封装敏感列（通过视图隐藏部分字段）、提供稳定接口给应用程序。对于更新操作，要记住单表简单视图才可更新，涉及聚合、连接、去重的视图一律只读。在设计数据库初期就明确视图的职责，可以避免后期维护时遇到修改限制带来的麻烦。