视图本身不存储数据且不能直接建索引，其查询能否使用索引取决于优化器是否能在重写后的基表访问中命中已有索引；关键在于避免在视图中对索引列使用函数等阻碍索引使用的操作。
视图本身不存储数据，索引不能直接建在视图上
SQL 视图（VIEW）只是保存的 SELECT 语句定义，不占用实际存储空间，也不支持直接创建索引。你执行 CREATE INDEX ON my_view (col) 会报错，比如 MySQL 提示 ERROR 1347 (HY000): 'db.my_view' is not BASE TABLE，SQL Server 也会拒绝——因为视图不是基表。
真正起作用的是底层基表上的索引。视图查询能否走索引，完全取决于它展开后的实际执行计划是否能命中基表已有的索引。
- 视图查询被重写为对基表的访问，优化器决定是否使用索引
- 如果视图里有
WHERE、JOIN、ORDER BY等操作，且涉及列已有合适索引，就可能触发索引查找（index seek） - 若视图包含聚合、
DISTINCT、子查询嵌套过深或计算列，容易导致优化器放弃索引，退化为扫描
如何让视图查询实际用上索引
关键不是“给视图加索引”，而是确保视图定义和调用方式能让优化器识别并选择基表索引。常见有效做法：
- 视图中避免对索引列使用函数：比如
WHERE YEAR(order_date) = 2023会让order_date上的索引失效；应改写为WHERE order_date >= '2023-01-01' AND order_date - 视图参数尽量传递为字面量或绑定变量（而非表达式），例如
SELECT * FROM v_orders WHERE status = ?比status = UPPER(?)更易走索引 - 联合查询类视图，确保
JOIN条件列在基表上有索引，如orders.customer_id和customers.id都需有索引 - 若视图常用于分页（
LIMIT/OFFSET或TOP N），应在排序字段上建索引，比如CREATE INDEX idx_orders_created ON orders(created_at)
物化视图是少数能“间接索引”的例外
标准 SQL 的视图不可索引，但部分数据库提供物化视图（MATERIALIZED VIEW）——它把查询结果物理落地为一张表。这类对象可以像普通表一样建索引。
- PostgreSQL 支持物化视图，可对其执行
CREATE INDEX ON mv_orders (status) - Oracle 的物化视图也支持索引，且能自动刷新
- SQL Server 没有原生物化视图，但可用带唯一聚集索引的索引视图（
INDEXED VIEW）替代：必须满足严格条件（如SCHEMABINDING、确定性函数、无*） - MySQL 完全不支持物化视图或索引视图，只能靠应用层缓存或冗余表模拟
注意：CREATE UNIQUE CLUSTERED INDEX 在 SQL Server 索引视图上是强制要求，否则无法启用；一旦创建，该视图就具备了物理存储和索引能力，但会增加写入开销。
验证视图是否真用了索引
别猜，要看执行计划。不同数据库命令略有差异，但核心字段一致：
- MySQL：用
EXPLAIN SELECT * FROM v_recent_orders WHERE user_id = 123，重点看key是否非NULL、type是否为ref或range、rows是否显著小于表总行数 - SQL Server：用
SET STATISTICS XML ON后执行查询，观察执行计划中是否有Index Seek节点，而非Table Scan或Clustered Index Scan - PostgreSQL：用
EXPLAIN (ANALYZE, BUFFERS) SELECT ... FROM v_summary，检查是否出现Index Scan并对比Buffers使用量
一个容易被忽略的点：即使视图定义简单，如果调用时传入的条件无法下推（比如通过 ORM 自动生成的动态 SQL 包裹了一层子查询），也可能绕过索引。最终生效的永远是“实际执行的那条 SQL”，不是视图名字。
