我来帮你拆解这个视图的优化思路，结合你提到的索引和物化视图，给你可落地的具体步骤：

首先先理清楚原视图的执行逻辑：它通过两层子查询关联proposals和comments，标记出没有评论时间的提案，再按用户分组计算未评论提案的占比。每次查询都要实时完成连接、聚合，数据量大的时候性能瓶颈会很明显。

一、先搞索引优化（成本最低，见效快） #

索引的核心是帮数据库快速定位数据，减少全表扫描的开销：

• 给comments表建复合索引，覆盖所有连接字段和判断用的msg_date：

  CREATE INDEX idx_comments_join ON comments(nick, club, title, director, msg_date);
  

  这个索引包含了左连接的所有关联键，同时带上msg_date，数据库做连接时直接从索引里就能判断有没有匹配的评论记录，不用回表查原数据，能省不少时间。
• 给proposals表建复合索引，覆盖分组字段和连接需要的字段：

  CREATE INDEX idx_proposals_group ON proposals(member, club, title, director);
  

  这里member是分组用的nick，加上连接需要的其他字段，能加速分组和连接操作，避免全表扫描。

二、用物化视图（适合数据更新不频繁的场景） #

如果你的proposals和comments数据不是秒级更新，或者可以接受一定的延迟，物化视图绝对是提升性能的杀招——它会把计算好的结果提前存在表里，查询时直接读结果，不用实时计算：

1. 先创建基础物化视图：

   CREATE MATERIALIZED VIEW mv_CP_aragna
   BUILD IMMEDIATE -- 立即生成初始数据
   REFRESH COMPLETE ON DEMAND -- 按需全量刷新，适合数据更新不频繁的情况
   AS
   SELECT nick, 100*sum(nuls)/count('c') pct_aragna
   FROM (
       SELECT member nick, club, title, director, NVL2(msg_date,0,1) nuls
       FROM proposals
       LEFT OUTER JOIN comments USING(nick,club,title,director)
   )
   GROUP BY nick
   HAVING sum(nuls)>0
   ORDER BY pct_aragna desc;
   

2. 如果需要近实时刷新，就得给基表建物化视图日志：

   -- 给proposals建日志，支持快速刷新
   CREATE MATERIALIZED VIEW LOG ON proposals WITH PRIMARY KEY, ROWID;
   -- 给comments建日志
   CREATE MATERIALIZED VIEW LOG ON comments WITH PRIMARY KEY, ROWID;
   

   然后把物化视图的刷新方式改成REFRESH FAST ON COMMIT——这样每次基表数据提交时，物化视图会自动快速更新，不用全量重算。但要注意，这种方式会增加写操作的开销，适合写频率不高的业务场景。
3. 最后给物化视图加个索引，加速排序查询：

   CREATE INDEX idx_mv_pct_aragna ON mv_CP_aragna(pct_aragna desc);
   

三、改写SQL语句（减少冗余，让优化器更聪明） #

原视图嵌套了两层子查询，其实可以简化成单层，Oracle的优化器更容易识别逻辑，生成更高效的执行计划：

CREATE OR REPLACE VIEW CP_aragna AS
SELECT 
    p.member AS nick,
    100 * SUM(NVL2(c.msg_date, 0, 1)) / COUNT('c') AS pct_aragna
FROM proposals p
LEFT OUTER JOIN comments c 
    ON p.member = c.nick 
    AND p.club = c.club 
    AND p.title = c.title 
    AND p.director = c.director
GROUP BY p.member
HAVING SUM(NVL2(c.msg_date, 0, 1)) > 0
ORDER BY pct_aragna desc
WITH READ ONLY;

去掉冗余的子查询后，优化器能更好地判断连接和聚合的顺序，说不定能直接用上咱们刚才建的索引。

四、怎么验证优化效果？ #

• 用EXPLAIN PLAN看执行计划，对比优化前后的逻辑读、物理读：

  EXPLAIN PLAN FOR SELECT * FROM CP_aragna;
  SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
  

• 或者用SET AUTOTRACE ON执行查询，看实际的执行统计，确认性能有没有提升。

内容的提问来源于stack exchange，提问作者Jorge Lizcano