视图爆out of memory或error 2013，90%是执行路径失控：数据库将百万行全载入内存排序/join，而非下推limit；一眼识别物化——mysql中explain显示select_type=derived且rows接近总行数，postgresql中plan rows远大于limit值即未下推。
查视图爆 Out of memory 或 ERROR 2013: Lost connection，90% 不是内存真不够，而是执行路径失控——数据库把几百万行全拉进内存再排序、分组或 JOIN。调 sort_buffer_size 或 work_mem 只会让崩溃来得更慢、更隐蔽。
怎么一眼识别视图是否被强制物化？
物化是内存爆炸的起点。MySQL 遇到含 GROUP BY、DISTINCT、子查询或 UNION 的视图，会放弃 MERGE 策略，改走 DERIVED 路径；PostgreSQL 则可能标记为 Materialize 或 CTE Scan。
- MySQL：运行
EXPLAIN SELECT * FROM my_view LIMIT 10，看select_type是否为DERIVED，且rows接近底层表总行数（比如显示 4800000） - PostgreSQL：运行
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM my_view LIMIT 10，重点看Plan Rows—— 若远大于 10（如 3200000），说明没下推 - 附加验证：
SHOW STATUS LIKE 'Created_tmp_disk_tables'持续上涨，且与Created_tmp_tables比值 > 15%，基本坐实落盘
为什么删掉视图里的 ORDER BY 很关键？
视图定义中写 ORDER BY created_at DESC，外层再加 LIMIT 10，数据库大概率不合并逻辑。排序发生在截断之前，等于要求全量数据进内存排一遍。
- MySQL 5.7+ 仅对无聚合、无窗口函数的简单视图支持
ORDER BY+LIMIT下推；一旦含HAVING或子查询，立刻失效 - PostgreSQL 对含
LATERAL、CTE或嵌套子查询的视图，优化器几乎从不下推ORDER BY - 真正安全的做法：视图里删掉所有
ORDER BY，调用方显式写ORDER BY id DESC LIMIT 10，且确保id有索引
哪些操作会悄悄放大中间结果集？
看似无害的写法，常触发基数误估或字段膨胀，让临时表体积翻几倍。
- 用
SELECT *查视图：尤其当底层含TEXT、BLOB或长VARCHAR字段时，MySQL 会直接强制落盘到磁盘临时表 - 视图 A 引用视图 B，B 里有
DISTINCT，A 再跟千万级表JOIN—— 优化器可能把本该 1 万行的结果误估成 50 万行，触发tempdbspill - 在
WHERE或ORDER BY中用函数：如JSON_EXTRACT(data, '$.name')或UPPER(name)，导致索引失效，只能全表扫描后排序 - 没建联合索引：比如视图常按
status = 'active'和created_at DESC查询，但只对created_at单独建了索引
什么时候该放弃视图，直接重写查询？
当 EXPLAIN 显示物化不可避免、且业务只要前 N 条时，手动控制执行边界比依赖视图更可靠。
- 把
SELECT * FROM my_view LIMIT 20改成：SELECT id, name, status FROM (SELECT t1.id, t1.name, t2.status FROM t1 JOIN t2 ON t1.id = t2.t1_id) AS v WHERE v.status = 'active' ORDER BY v.id DESC LIMIT 20 - JOIN 多张大表时，优先考虑分批：用主键范围分片（如
WHERE id BETWEEN 100000 AND 200000）代替单次全量关联 - 应用层启用流式读取：JDBC 加参数
?useCursorFetch=true&defaultFetchSize=100，避免驱动一次性把全部结果加载进 JVM 堆
最易被忽略的一点：物化不是“视图的问题”，而是“你没告诉数据库你到底要什么”。索引缺失、字段冗余、排序固化、嵌套层级过深——这些才是真正的内存杀手。执行计划永远比配置参数诚实。
