视图不存储数据，GROUP BY无法自动继承基表聚簇索引顺序；若视图含DISTINCT、UNION、GROUP BY、ORDER BY+LIMIT、子查询或窗口函数，优化器将物化中间结果，导致Using temporary，索引失效。
视图本身不存储数据，GROUP BY 无法自动继承基表聚簇索引的物理顺序——因为执行时是否能下推排序逻辑，取决于视图定义能否被优化器完整内联，而不是“有没有索引”。
视图定义破坏了索引访问路径，GROUP BY 就会退化为物化+排序
只要视图里出现以下任一结构，MySQL/PostgreSQL 就大概率放弃内联，转而先物化中间结果（生成临时表），此时基表的聚簇索引顺序彻底失效：
-
DISTINCT、UNION、GROUP BY出现在视图定义中（哪怕只是 SELECT * FROM v GROUP BY x，v 本身含 GROUP BY） -
ORDER BY+LIMIT组合（MySQL 中极易触发Using temporary） - 子查询出现在
FROM子句，如(SELECT ... ) AS v -
WITH RECURSIVE或窗口函数（即使没聚合，也强制物化）
验证方式：对视图执行 EXPLAIN FORMAT=TREE（MySQL 8.0+）或 EXPLAIN (VERBOSE)（PostgreSQL），看到 Materialize 或 Temp Table 节点，就说明聚簇索引已不可用。
即使视图可内联，GROUP BY 字段顺序也必须严格匹配索引最左前缀
假设基表有聚簇索引 (a, b, c)，视图定义是 SELECT a, b, COUNT(*) FROM t GROUP BY a, b，且被成功内联——这时才能利用索引顺序避免 Using filesort。但一旦出现以下情况，索引就白建了：
- 视图中写成
GROUP BY b, a（字段顺序错） - SQL 查询在视图基础上再加
WHERE c > '2024'（范围条件中断最左前缀，c后的索引字段失效） - 视图 SELECT 中包含未索引的字段，如
SELECT a, b, MAX(d)，而d不在索引里 → 触发回表，可能连带让 GROUP BY 放弃索引
SQL Server 的索引视图是例外，但限制极多
只有 SQL Server 支持真正意义上的“视图拥有自己的聚簇索引”，但需同时满足：
- 视图创建时指定
SCHEMABINDING - 所有引用对象（表、列）都用两段式名称（
schema.table） - 创建唯一聚集索引前，必须确保结果集行唯一（常靠
UNIQUE+NOT NULL列组合） - 查询要命中该索引视图，还必须开启 5 个会话选项，例如
SET NUMERIC_ROUNDABORT OFF
MySQL 和 PostgreSQL 完全不支持这种机制；它们的“物化视图”是独立功能（如 PostgreSQL 的 CREATE MATERIALIZED VIEW），和普通视图语法分离，也不自动关联基表索引。
最容易被忽略的一点：你以为在对视图做 GROUP BY，其实优化器早已把它重写成嵌套子查询 —— 此时你查的不是“基表索引”，而是内存/磁盘临时表，物理顺序早就没了。
