视图中使用group by会禁用索引下推（icp），因分组聚合强制在server层执行，导致where条件无法下推至存储引擎；explain中“using where”替代“using index condition”即为icp失效标志。
视图里写GROUP BY会让MySQL放弃索引下推（ICP）
因为GROUP BY强制MySQL在Server层完成分组聚合，无法将WHERE条件安全地下推到InnoDB引擎层执行。一旦视图定义中含GROUP BY，优化器就认为该结果集不可预测——它可能被物化、重排序、甚至因聚合丢失原始行结构，所以直接禁用ICP。你能在EXPLAIN的Extra字段里看到“Using where”取代了“Using index condition”，这就是ICP失效的明确信号。
GROUP BY视图导致联合索引非最左列过滤完全失效
比如你有联合索引(region, age)，正常查询WHERE region = 'East' AND age > 25能走ICP，age > 25由引擎层直接过滤。但若这个条件出现在基于该表的GROUP BY视图上（如CREATE VIEW v AS SELECT region, COUNT(*) FROM t GROUP BY region），哪怕外层再加WHERE age > 25，也根本无效——视图里压根没age字段，更别说索引下推了。常见错误现象包括：
- 查询返回空结果或报错
Unknown column 'age' in 'where clause' - 试图在视图上
WHERE一个未出现在SELECT列表里的原始列，直接失败 - 即使视图
SELECT里包含了age，只要它参与了GROUP BY或被聚合函数包裹，原始索引结构就已不可见
PostgreSQL和MySQL对GROUP BY视图的处理差异
PostgreSQL允许在GROUP BY视图上建索引（如CREATE INDEX ON sales_by_day_region (stat_date, region)），但这只是加速视图查询本身，并不恢复底层基表的ICP能力；MySQL连视图索引都不支持，且5.7/8.0均会把含GROUP BY的视图默认物化为派生表，彻底切断与原始索引的关联。关键点在于：
- MySQL 8.0+ 的
WITHCTE如果含GROUP BY，默认不物化，可能被内联展开——反而让问题更隐蔽 - 想强制物化，得加
/*+ MATERIALIZE */提示，否则优化器可能忽略你的意图 - 即便物化成功，派生表本身无索引，外层
WHERE仍只能在Server层过滤，无法触发ICP
真正能保留ICP的替代方案
别在视图定义里塞GROUP BY，把聚合逻辑留给调用方。如果必须复用聚合逻辑，优先考虑：
- 用普通表模拟物化视图：定时跑
INSERT INTO summary_table SELECT ... GROUP BY ...，并在该表上建索引 - 对高频固定维度聚合，建覆盖索引+冗余字段（如把
YEAR(create_time)存成整型列并索引） - 用窗口函数替代部分GROUP BY场景，例如取每组最新记录用
ROW_NUMBER() OVER (PARTITION BY x ORDER BY y DESC)，避免分组后回表
复杂点在于：视图是逻辑封装，而ICP依赖物理索引路径——两者天然冲突。一旦你把GROUP BY写进视图，就等于主动放弃了引擎层的过滤能力，后续所有优化都只能在Server层打补丁。
