sql视图不支持存储型计算列，计算字段每次查询都需重新计算且无法索引；应将计算下沉至基表，使用persisted（sql server）或stored生成列（mysql/postgresql）并建立索引以提升性能。
SQL视图本身不支持直接定义「存储型计算列」——视图里的计算字段只是逻辑表达式，每次查询都会重新计算，无法索引，也不能持久化。
SQL Server 视图中用 ISNULL(first_name,'') + ' ' + ISNULL(last_name,'') 会拖慢查询
这种写法在视图定义里很常见，但执行时每行都要做字符串拼接和空值判断。当底层表有几百万行、又参与 JOIN 或 WHERE 过滤时，CPU 开销陡增，执行计划里常出现「Compute Scalar」算子+粗箭头，意味着中间结果集爆炸（比如四千四百万行）。
- 视图不保存数据，
full_name是每次查询实时算的，哪怕你只查id = 123，SQL Server 仍可能先算完全部行再过滤 - 无法在视图列上建索引（SQL Server 不允许对普通视图的计算列建索引）
- 如果上层应用频繁按
full_name搜索，WHERE full_name LIKE 'John%'必然全表扫描
真正能加速的方案是：把计算下沉到基表，用 PERSISTED 计算列 + 索引
不是在视图里加计算，而是在源表（如 users）上添加物理存储的计算列，再让视图引用它。这样既保持视图逻辑简洁，又能让查询走索引。
- 执行
ALTER TABLE users ADD full_name AS ISNULL(first_name,'') + ' ' + ISNULL(last_name,'') PERSISTED - 再建索引：
CREATE INDEX IX_users_full_name ON users(full_name) - 视图就可以简化为
SELECT id, first_name, last_name, full_name FROM users，不再含表达式 - 注意：
PERSISTED列会占用磁盘空间，且更新first_name或last_name时自动重算，但换来的是可索引性和稳定性能
MySQL / PostgreSQL 要用生成列（Generated Column）替代视图计算
MySQL 5.7+ 和 PostgreSQL 12+ 支持 STORED（MySQL）或 STORED + INDEX（PostgreSQL）生成列，原理类似 SQL Server 的 PERSISTED，但语法不同：
- MySQL：
ALTER TABLE users ADD full_name VARCHAR(200) GENERATED ALWAYS AS (CONCAT(IFNULL(first_name,''), ' ', IFNULL(last_name,''))) STORED，然后CREATE INDEX idx_full_name ON users(full_name) - PostgreSQL：
ALTER TABLE users ADD COLUMN full_name TEXT GENERATED ALWAYS AS (COALESCE(first_name, '') || ' ' || COALESCE(last_name, '')) STORED，再CREATE INDEX idx_full_name ON users(full_name) - 别指望在视图里用
GENERATED—— 它只能定义在基表上；视图引用该列才有效
最易被忽略的一点：视图加速的关键从来不在“怎么写视图”，而在于“计算发生在哪一层”。把计算留在视图里，等于把性能瓶颈公开暴露给每一次调用；把它固化在基表并索引，才能真正切断重复计算链。
