查视图爆out of memory或error 2013主因是执行路径失控，非缓冲区过小；应检查explain确认是否物化（derived/materialize）、排序与limit是否下推、索引是否覆盖，优先重写查询或建覆盖索引，而非调sort_buffer_size或work_mem。
查视图爆 Out of memory 或 ERROR 2013: Lost connection，90% 不是视图本身的问题，而是执行路径失控——MySQL 强制物化、PostgreSQL 无法下推排序、中间结果集全量加载进内存。调 sort_buffer_size 或 work_mem 只会让崩溃来得更慢、更隐蔽。
MySQL 视图含 GROUP BY/DISTINCT/子查询时强制物化，全量数据进内存
MySQL 遇到带聚合、去重或非相关子查询的视图，会放弃 MERGE 策略，改用 DERIVED 表物化——整个中间结果集先生成临时表再处理。哪怕你只想要 10 条，它也得把几百万行全读进内存排一遍。
- 用
EXPLAIN SELECT * FROM my_view LIMIT 10看select_type：出现DERIVED就坐实了物化 - 视图定义里有
ORDER BY created_at DESC，外层再加LIMIT 10？MySQL 5.7+ 虽支持下推，但前提是没用GROUP BY、HAVING或窗口函数；否则照样全排 - 别在视图里写
ORDER BY——排序逻辑交给调用方，且必须确保ORDER BY字段（如id）有索引；否则Using filesort+ 全表扫描 = 必爆内存
PostgreSQL 视图里写了 ORDER BY，外层 LIMIT 不下推
PostgreSQL 对简单视图能下推 ORDER BY ... LIMIT，但一旦视图含 CTE、LATERAL、或嵌套子查询，优化器大概率放弃下推。结果就是：全量排序 → 再截断 → 内存吃满。
- 验证是否下推：
EXPLAIN (VERBOSE, ANALYZE) SELECT * FROM my_view LIMIT 10，看Plan Rows是接近总行数（没下推），还是明显变小（已下推） - 手动重写比依赖视图更可靠：
SELECT * FROM (SELECT ... FROM t1 JOIN t2 ...) AS v ORDER BY v.id DESC LIMIT 10，显式控制排序和截断位置 - 避免在视图定义中固化
ORDER BY；若业务强依赖固定顺序，改用主键或带索引的时间字段，并在外层明确加ORDER BY id DESC LIMIT 10
JOIN 多张大数据表时，分批查询比调内存参数更可控
大表 JOIN 爆内存，本质是数据库试图把右表全载入内存建哈希表。这时调 work_mem（PG）或 join_buffer_size（MySQL）风险极高：单次撑住，高并发一来立刻全局 OOM。
- 拆成两步：先按主键范围分页取左表 ID（用游标式，不用
LIMIT OFFSET），再用IN拉右表关联数据 - 示例（PG/MySQL 通用）：
SELECT id FROM orders WHERE id > 1000000 ORDER BY id LIMIT 1000;
SELECT o.*, u.name FROM orders o JOIN users u ON o.user_id = u.id WHERE o.id IN (1000001, ..., 1001000);
-
IN列表长度建议 ≤ 1000；左右表的关联字段（如user_id、id）必须有索引，否则IN退化为全表扫描 - MySQL 下尤其注意：MyISAM 表用
IN可能触发表级锁，务必切 InnoDB 并在事务中加FOR UPDATE显式控制
别碰 sort_buffer_size / work_mem —— 它们不是解药，是遮羞布
调大 sort_buffer_size（MySQL）或 work_mem（PG）只会让单次排序撑得更久，掩盖真实问题：缺失索引、物化失控、执行计划退化。并发一上来，多个连接同时申请几 MB 缓冲，innodb_buffer_pool_size 或系统内存直接被吃光。
- 真正该盯的是
EXPLAIN输出里的rows值：如果接近底层表总行数（比如 500 万），但你只要 10 条，说明根本没走索引、也没下推 -
sort_buffer_size再大，也救不了ORDER BY updated_at字段没索引的查询；此时唯一有效动作是建覆盖索引：CREATE INDEX idx_status_updated ON t1(status, updated_at) - 物化视图 + 全量排序 + 缺索引 = 三重内存杀手；参数调优永远只是最后手段，且必须配合
EXPLAIN验证效果
最常被忽略的一点：视图 OOM 的根因几乎从不在于“缓冲区太小”，而在于“执行计划没被约束”。与其花时间试错调参，不如花五分钟跑一次 EXPLAIN，确认 ORDER BY 和 LIMIT 是否真正下推、JOIN 是否走了索引、中间结果集是否被强制物化——这些才是决定内存用量的关键开关。
