为什么执行复杂的SQL视图会导致临时表空间爆满-SQL-PHP中文网

根本原因是视图含group by、distinct、union或子查询时，mysql放弃merge优化而强制物化，导致外层where/order by无法下推，explain中select_type为derived且extra含using temporary或using filesort。

为什么执行复杂的sql视图会导致临时表空间爆满

根本原因不是视图本身，而是数据库执行时被迫物化中间结果、又没索引支撑排序/分组——调大 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) 做排序/分组——函数表达式会阻断索引下推，强制计算后进临时表