视图内存溢出根因是执行路径失控而非sort_buffer_size过小；应检查执行计划、移除视图内ORDER BY并确保索引覆盖、必要时重写查询，参数调优仅作最后手段。
sort_buffer_size 调大不能解决视图内存溢出，反而可能掩盖真实问题、加剧全局 OOM 风险。
视图 OOM 的根因不是缓冲区小，而是执行路径失控
MySQL/PostgreSQL 查视图时爆 Out of memory 或 ERROR 2013: Lost connection，90% 不是因为 sort_buffer_size 太小，而是以下任一情况发生：
- MySQL 中视图含
GROUP BY、DISTINCT或子查询 → 强制物化为DERIVED表，全量数据进内存再排序 - PostgreSQL 视图里写了
ORDER BY created_at DESC，外层再加LIMIT 10→ 优化器未下推排序，导致全表排序后截断 -
EXPLAIN显示rows接近视图底层表总行数（比如 500 万），但业务只要 10 条 → 说明没走索引 + 没下推
调高 sort_buffer_size 只会让单次排序撑得更久，一旦并发上来，多个连接同时申请几 MB 缓冲，innodb_buffer_pool_size 或系统内存直接被吃光。
真正该做的三件事
先看执行计划
运行EXPLAIN SELECT * FROM my_view WHERE status = 'active' ORDER BY updated_at DESC LIMIT 20
重点检查：select_type是否为DERIVED（MySQL）或MATERIALIZED（PG）；Extra是否含Using filesort且没走索引删掉视图里的
ORDER BY
视图是逻辑封装，不该固化顺序。把排序交给调用方：SELECT * FROM my_view WHERE status = 'active' ORDER BY updated_at DESC LIMIT 20
并确保updated_at字段有索引（单列或复合索引前导）-
手动重写替代视图调用（当必须复用逻辑时）
把SELECT * FROM my_view LIMIT 10改成：SELECT * FROM ( SELECT t1.id, t1.name, t2.amount FROM orders t1 JOIN payments t2 ON t1.id = t2.order_id WHERE t1.status = 'active' ) AS v ORDER BY v.updated_at DESC LIMIT 10
这样能控制 WHERE 下推时机，避免物化整张派生表
如果非调参数不可，只动这一个
- MySQL：优先调
tmp_table_size和max_heap_table_size（两者需相等），防止中间结果被迫落盘再读，比狂拉sort_buffer_size更安全 - PostgreSQL：调
work_mem要极其谨慎，它按每个排序/哈希操作单独分配，16MB × 20 并发 = 320MB 内存占用，建议从 4MB 起步，配合EXPLAIN ANALYZE观察实际使用量
视图不是黑盒，OOM 是数据库在喊你去看它的执行路径——别急着加内存，先让 EXPLAIN 说话。
