SQLite 视图怎么用，什么时候不该用？

SQLite 视图是把一段 SELECT 查询保存成一个可复用的虚拟表。它不存储查询结果，只保存查询定义；每次查询视图时，SQLite 都会展开这段 SQL，再去读取底层表。它适合封装复杂 JOIN、统一统计口径、隐藏敏感字段，也适合给应用层一个更稳定的查询接口。但要先说清楚：普通视图不是缓存，底层查询慢，视图通常也不会变快。

sql
CREATE VIEW user_order_summary AS
SELECT u.id, u.name, COUNT(o.id) AS order_count, SUM(o.amount) AS total_amount
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.status = 'active'
GROUP BY u.id, u.name;

SELECT * FROM user_order_summary WHERE order_count >= 3;

追问

视图和表有什么区别？

表保存真实数据，视图只保存查询定义，这是最核心的区别。查询视图时，SQLite 会把它当成一段可复用 SQL 来执行，所以性能主要取决于底层表、索引和查询条件。取舍在于视图让代码更清楚、更稳定，但不能替代合理建表和索引。常见踩坑是把大聚合视图当报表缓存，结果页面每打开一次就重新扫一遍订单表。

SQLite 视图能不能更新？

默认不能直接对普通视图执行 INSERT、UPDATE、DELETE，因为 SQLite 不一定知道这些写入该落到哪张表。简单场景可以用 INSTEAD OF 触发器，把对视图的写入转发到底层表。这个方案适合字段映射明确的单表视图，不适合带聚合、分组或复杂 JOIN 的视图。边界很清楚：一旦视图里出现 GROUP BY、COUNT() 这类结果，更新语义就容易变得含糊。

sql
CREATE VIEW active_user_names AS
SELECT id, name FROM users WHERE status = 'active';

CREATE TRIGGER active_user_names_update
INSTEAD OF UPDATE ON active_user_names
BEGIN
  UPDATE users SET name = NEW.name WHERE id = OLD.id;
END;

视图能提升查询性能吗？

普通 SQLite 视图通常不能提升性能，因为它不是物化视图，也不会自动保存中间结果。真正决定速度的是底层 SQL 能不能走索引，例如 JOIN 字段、WHERE 字段、排序字段是否建了合适索引。取舍是视图负责抽象和复用，性能优化仍要回到底层查询计划。若高频统计确实很慢，可以维护一张汇总表，但这会带来同步和一致性成本。

sql
CREATE INDEX idx_orders_user_id ON orders(user_id);
CREATE INDEX idx_users_status ON users(status);

什么时候适合用视图隐藏字段？

当应用只需要公开信息，而不应该读取密码哈希、手机号、内部备注时，视图很有用。比如只暴露 id、name、avatar_url，查询代码天然看不到敏感列。要注意 SQLite 没有内置用户权限体系，视图本身不是完整安全边界。真正的边界还要靠数据库文件权限、应用层鉴权和接口校验配合。

sql
CREATE VIEW public_users AS
SELECT id, name, avatar_url FROM users WHERE deleted_at IS NULL;

修改视图定义要注意什么？

SQLite 没有通用的 ALTER VIEW，通常要先 DROP VIEW 再重新 CREATE VIEW。这很直接，但要先检查依赖它的查询、触发器和迁移脚本。取舍是重建最快，风险是旧代码可能还在读取被删除的列。稳妥做法是先新增兼容视图或保留旧列，等应用发布完成后再清理。

SQLite 视图适合解决“SQL 太散、字段不该暴露、查询口径要统一”的问题。它让数据库接口更干净，但不会神奇地让慢查询变快；只要记住这一点，视图通常会是一个很稳的抽象层。