根本原因是视图强制物化且缺乏索引支撑排序/分组，导致全量数据进入临时表；需通过EXPLAIN识别DERIVED+Using temporary、建联合索引、精简字段、避免函数表达式等优化执行路径，而非仅调大tmp_table_size。
查视图导致临时表空间溢出，根本原因不是视图本身，而是数据库执行时被迫物化中间结果、又没索引支撑排序/分组——调大 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)做排序/分组——函数表达式无法走索引，必走临时表
为什么调大 tmp_table_size 和 max_heap_table_size 还是溢出
这两个参数必须设成完全相等才有效，MySQL 实际取的是 min(tmp_table_size, max_heap_table_size)。很多人只改了前者，后者还卡在默认 16MB，结果白调。
- 检查当前值：
SELECT @@tmp_table_size, @@max_heap_table_size;，确认是否一致 - 在
my.cnf的[mysqld]段里同步设置，例如：tmp_table_size = 512M和max_heap_table_size = 512M - 重启后验证生效，但注意：该配置仅对新连接生效；已有连接需重连或手动
SET SESSION - 调太高反而危险——并发 50 个查询各占 512MB，就是 25GB，可能直接触发系统 OOM
真正容易被忽略的是：视图里一个没索引的 ORDER BY updated_at，哪怕只查 10 行，也会把整张表拉进内存排序。索引不是可选项，是保命线。
