视图查询慢的本质是底层SQL缺失索引，因视图仅封装SELECT语句、不存数据且无自带索引，查询时会内联展开为原始SQL；需为基表的WHERE、JOIN、ORDER BY等字段建合适复合索引，并避免SELECT*和函数导致索引失效。
视图查询慢，本质是底层SQL没索引
视图本身不存数据，也不自带索引——它只是个封装好的 SELECT 语句。你查视图时，数据库会把视图定义“内联展开”，再跑一遍完整查询。所以视图慢，99% 是因为展开后的 SQL 没走索引，或者走了但没走对。
比如视图定义为：CREATE VIEW v_user_orders AS SELECT u.name, o.amount FROM users u JOIN orders o ON u.id = o.user_id WHERE u.status = 'active'；当你执行 SELECT * FROM v_user_orders WHERE o.amount > 100，实际等价于在展开后加了这个条件，但 orders.amount 若无索引，就会全表扫描。
- 先用
EXPLAIN（MySQL）或图形化执行计划（SQL Server）看视图查询展开后的实际访问路径，重点找type=ALL、Scan类操作符 - 不是给视图建索引，而是给视图里涉及的每张基表建索引：WHERE 条件列、JOIN ON 列、ORDER BY 列、GROUP BY 列都要覆盖
- 特别注意复合索引顺序：例如视图中常查
WHERE user_id = ? AND status = 'active' ORDER BY create_time DESC，那就建idx_user_status_time，顺序不能颠倒
避免 SELECT * 和函数导致索引失效
视图定义里写 SELECT * 或带函数（如 UPPER(name)、YEAR(create_time)），会让优化器无法利用索引，尤其在外部查询再加过滤条件时，极易触发全表扫描。
典型失效场景：WHERE YEAR(create_time) = 2024 → 即使 create_time 有索引也无效；WHERE UPPER(email) = 'A@B.COM' → 索引列被函数包裹，直接失效。
- 视图定义中显式列出所需字段，不要用
SELECT *；哪怕只少选一列，也可能让覆盖索引生效 - 把函数操作从 WHERE 移到应用层或改写为范围条件：用
create_time >= '2024-01-01' AND create_time 替代 <code>YEAR(create_time) = 2024 - 若必须函数匹配，考虑建函数索引（如 PostgreSQL 的
LOWER(email)索引，或 MySQL 8.0+ 的函数索引）
执行计划里出现 Key Lookup 或 Sort 就得警惕
在 SQL Server 执行计划中看到 Key Lookup（书签查找），或在 MySQL/PostgreSQL 中看到 Using filesort，说明虽然走了索引，但还要回表取额外字段或排序，I/O 和 CPU 开销陡增。
比如视图返回 name, email, phone, status，但索引只有 (status)，那查 WHERE status = 'pending' 就会先索引定位，再逐行回表取其他三列——百万行就是百万次随机 I/O。
- 优先建覆盖索引：把 SELECT 字段和 WHERE/GROUP BY 字段一起放进索引，用
INCLUDE（SQL Server）或联合列（MySQL）方式 - 确认外部查询是否下推谓词：有些数据库（如 SQL Server）能把
WHERE条件“下推”到视图内部执行，但前提是视图定义没阻断（比如含DISTINCT、UNION、聚合 + 无 GROUP BY） - 如果执行计划里
Sort成本占比高，检查是否能通过索引顺序满足ORDER BY，避免额外排序
复杂视图不如拆成 CTE 或物化方案
当视图嵌套多层、含多个 JOIN、UNION ALL、窗口函数或聚合时，优化器很难生成高效计划，统计信息也容易失真，索引利用率大幅下降。
某金融系统曾有一个含 7 表关联 + 3 层子查询的视图，查询耗时 2.3s；拆成带索引的中间临时表后降到 86ms；改用 SQL Server 的索引视图（物化视图）后稳定在 12ms，但代价是写入延迟增加。
- 高频读、低频写的场景，可评估索引视图（SQL Server）或物化视图（PostgreSQL）——它们会真实存储结果，但需权衡 DML 性能损失
- 中等复杂度视图，改用 CTE 替代：CTE 更易读，且现代优化器（MySQL 8.0+、PostgreSQL 12+）通常能内联展开并复用索引
- 真正复杂的报表逻辑，别硬塞进视图，用应用层分步计算 + 缓存更可控
索引和执行计划不是调一次就完事的事——表数据量变化、统计信息过期、查询参数分布偏移，都可能让昨天高效的计划今天变慢。最危险的不是没索引，而是有了索引却没验证它真被用了。
