根本原因是视图含GROUP BY、DISTINCT、UNION或子查询时，MySQL放弃MERGE优化而强制物化，导致外层WHERE/ORDER BY无法下推，EXPLAIN中select_type为DERIVED且Extra含Using temporary或Using filesort。
根本原因不是视图本身，而是数据库执行时被迫物化中间结果、又没索引支撑排序/分组——调大 tmp_table_size 或临时表空间大小只是掩耳盗铃。
MySQL 视图被强制物化时怎么识别
视图定义里只要含 GROUP BY、DISTINCT、UNION 或子查询，MySQL 就大概率放弃 MERGE 优化，改走 MATERIALIZED（即派生表）。这时 EXPLAIN 的 select_type 会显示 DERIVED，且 Extra 常带 Using temporary 或 Using filesort。
- 运行
EXPLAIN FORMAT=JSON SELECT * FROM my_view LIMIT 10;，重点看query_block->materialized_from_subquery是否为true -
rows列数值接近底层表总行数（比如视图基于千万级表，rows显示 9800000），说明排序/过滤没下推，全量数据已进临时表 -
SHOW STATUS LIKE 'Created_tmp_disk_tables';持续上涨，且与Created_tmp_tables比值 >15%，基本确认落盘
PostgreSQL 视图中 ORDER BY + LIMIT 为何不生效
PostgreSQL 不保证视图内的 ORDER BY 能被外层 LIMIT 下推。尤其当视图含 CTE、LATERAL 或窗口函数时，优化器常选择先全量物化再截断——sort_buffer_size 再大也救不了，因为排序发生在 LIMIT 之前。
- 用
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM my_view LIMIT 10;查看Plan Rows:；若远大于 10，说明未下推 - 删掉视图里的
ORDER BY created_at DESC，把排序逻辑交给调用方，外层显式写ORDER BY id DESC LIMIT 10 - 确保
id或created_at字段有索引；否则即使下推，也会触发 External sort 写磁盘临时文件
怎么让视图查询避开临时表
核心就两条：不让数据库“不得不”建临时表，以及帮它“轻松”完成排序/分组。
- 删掉视图里的
SELECT *，只选业务真需要的字段；尤其避开TEXT、BLOB、超长VARCHAR，它们会让临时表直接落盘 - 为视图中所有
ORDER BY、GROUP BY、JOIN条件字段建联合索引，例如CREATE INDEX idx_status_time ON orders (status, created_at); - 把带
LIMIT的查询重写为显式子查询：SELECT * FROM (SELECT id, name FROM t1 JOIN t2 ON t1.id = t2.t1_id) AS v ORDER BY v.id DESC LIMIT 20;，控制物化边界 - 避免在视图里用
JSON_EXTRACT(col, '$.name')或UPPER(name)做排序/分组——函数表达式会阻断索引下推，强制计算后进临时表
真正卡住性能的，往往不是数据量大，而是排序/分组逻辑落在了物化之后；而物化是否发生，取决于视图定义和底层索引是否匹配——这点最容易被忽略，也最难靠重启或扩容解决。
