MySQL视图不支持GROUP BY后保留非分组列，因only_full_group_by模式报错1055；正确做法是确保SELECT列全在GROUP BY中或用聚合函数包裹，替代方案包括物化表、CTE或存储过程。
MySQL 视图本身不支持直接在定义中使用 GROUP BY + 聚合函数后还保留非分组列（除非开启宽松模式），更不会“自动用临时表”——临时表是执行引擎内部行为，不是视图语法能控制的。你真正要解决的问题，是「如何让带聚合的逻辑可复用、可被其他查询引用」。
视图定义里写 GROUP BY 会报错 ERROR 1055
这是 sql_mode=only_full_group_by 的默认保护机制。比如下面这个定义会失败：
CREATE VIEW user_dept_stats AS SELECT dept, COUNT(*) c FROM user GROUP BY dept;
错误信息是：ERROR 1055 (42000): Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'user.dept' which is not functionally dependent on columns in GROUP BY clause。
原因不是语法错，而是 MySQL 拒绝模糊语义：如果 user 表里 dept 相同但其他字段不同，视图该返回哪一行？它要求 SELECT 列要么在 GROUP BY 中，要么被聚合函数包裹。
- ✅ 正确写法：所有非聚合列必须出现在
GROUP BY中，或用聚合函数包装 - ❌ 错误写法：
SELECT dept, name, COUNT(*) FROM user GROUP BY dept（name未聚合也未分组） - ⚠️ 勉强通过但危险：
SET sql_mode = ''关闭only_full_group_by，会导致结果不可预测（各版本取第一行策略不同）
为什么 EXPLAIN 显示 Using temporary 却不能在视图里“显式用临时表”
Using temporary 是执行计划里的提示，说明优化器决定走临时表路径——但它由数据分布、索引、WHERE 条件、排序需求共同触发，不是你能“在视图里写出来”的东西。视图只是保存 SELECT 语句，不干预执行路径。
常见触发场景：
-
GROUP BY字段无索引，且数据量大 → 强制建内存/磁盘临时表 + filesort -
ORDER BY和GROUP BY字段不一致，又没覆盖索引 → 额外排序需要临时表 -
HAVING条件复杂（如HAVING AVG(score) > 85）→ 必须等聚合完成才能过滤，无法下推
你不能在视图定义里加 SQL_BIG_RESULT 或调整 tmp_table_size，这些是查询执行时的 hint 或服务端配置，对视图定义无效。
替代方案：用物化思路绕过视图限制
如果目标是「复用聚合结果」，与其卡在视图语法，不如用更可控的方式模拟“物化”效果：
- ✅ 创建普通表 + 定时刷新：用
CREATE TABLE stats_cache AS SELECT ... GROUP BY ...，再配合事件调度器定期REPLACE INTO更新 - ✅ 用 CTE 替代简单场景：
WITH dept_stats AS (SELECT dept, COUNT(*) c FROM user GROUP BY dept) SELECT * FROM dept_stats JOIN other_table USING(dept)—— CTE 在 8.0+ 支持，逻辑清晰且不持久化 - ✅ 封装为存储过程：把聚合逻辑写进
PROCEDURE，调用时传参、查临时表、返回结果集，适合复杂条件组合 - ⚠️ 避免滥用
CREATE TEMPORARY TABLE：它只对当前连接可见，无法被其他会话或视图引用
真正容易被忽略的是：视图的“可维护性”远比“能否写 GROUP BY”重要。一旦视图里嵌套多层聚合+JOIN，后续排查 Using temporary 瓶颈时，你根本分不清是视图定义问题，还是调用它的外部查询拖慢了整体——所以优先把聚合逻辑下沉到表或过程里，留视图做轻量封装。
