SQL视图本身不导致内存泄漏，但SELECT *读取含LOB字段的视图会全量加载LOB数据至内存，引发OOM；根本原因在于执行路径中隐式全量加载，而非视图定义本身。
SQL视图本身不会导致内存泄漏，但读取含大对象（LOB）字段的视图时，若未控制加载行为，极易触发内存爆涨甚至 OOM —— 根本问题不在视图定义，而在查询执行路径中对 LOB 数据的隐式全量加载。
为什么 SELECT * FROM view 会把整个 LOB 字段塞进内存？
数据库在处理 SELECT * 时，即使你只打算显示前 100 字节，多数引擎（尤其是 SQL Server 和旧版 MySQL）仍会把整个 TEXT、NTEXT、IMAGE 或 XML 字段完整加载进内存，尤其当视图底层 JOIN 多张表且含多个 LOB 列时，内存消耗呈倍数增长。
- SQL Server 默认启用
text in row选项时，小 LOB（≤ 256 字节）存于数据页内，但大 LOB 始终走 LOB 存储结构，SELECT操作会触发完整的 LOB 页面链遍历和缓冲区分配 - MySQL 8.0+ 对
LONGTEXT使用动态行格式，但若未显式限制长度（如SUBSTRING(content, 1, 500)），优化器无法下推截断逻辑，结果集仍携带完整 LOB 数据 - PostgreSQL 的
TEXT虽支持 toast 压缩，但EXPLAIN ANALYZE中若出现Seq Scan on large_table+Heap Fetches高值，说明 toast 行被频繁回表读取，内存压力来自缓存未命中后的重复加载
如何安全读取视图中的 LOB 字段？
关键不是“禁用视图”，而是切断 LOB 全量加载路径。必须显式控制字段内容长度和加载时机。
- 永远避免
SELECT *：改用明确列出非 LOB 字段，并对 LOB 字段做长度约束，例如SUBSTRING(description, 1, 200)或LEFT(note, 500) - SQL Server 中慎用
ntext/text：已弃用，应迁至NVARCHAR(MAX)并配合READTEXT/TEXTPTR按需流式读取（仅限遗留系统）；新项目直接用varchar(max)+CONVERT(VARCHAR(500), content) - PostgreSQL 中用
pg_column_size()预估字段体积，结合WHERE pg_column_size(blob_col) < 10240过滤超大值，避免扫描时拖垮 shared_buffers - 应用层加字段级懒加载：比如 MyBatis 的
<result column="content" property="content" jdbcType="LONGVARCHAR"/>配合fetchSize="-2147483648"（即 STREAM 模式），让 JDBC 驱动按需拉取而非一次性缓存
视图里含 LOB 时，ORDER BY + LIMIT 为什么更危险？
这是最隐蔽的陷阱：你以为 LIMIT 10 能保命，但数据库可能先全量加载所有 LOB 再排序，最后才截断——排序过程本身就会把每个 LOB 字段完整读入 sort buffer。
- MySQL 5.7+ 对含
GROUP BY或窗口函数的视图不支持ORDER BY ... LIMIT下推，EXPLAIN中看到select_type = DERIVED就代表已物化整张中间表（含全部 LOB） - SQL Server 视图若含
ORDER BY，则必须搭配TOP才能生效；否则该ORDER BY被忽略，但若外层再套SELECT TOP 10 * FROM v_with_lob ORDER BY created_at，仍会强制加载全部 LOB 后排序 - 正确写法是把 LOB 截断提前到子查询：例如
SELECT id, title, SUBSTRING(content, 1, 300) AS preview FROM (SELECT id, title, content FROM posts WHERE status = 1) t ORDER BY created_at DESC LIMIT 10
LOB 字段索引与统计信息容易被忽略
没有索引的 LOB 字段会让优化器彻底失去估算能力，导致计划误判为“小结果集”，进而分配过小内存缓冲区，最终触发大量临时磁盘排序（Using filesort）或被迫升级为内存密集型操作。
- SQL Server 不允许直接对
XML或VARBINARY(MAX)建常规索引，但可建 XML 索引（PRIMARY XML INDEX）或计算列索引（如ALTER TABLE docs ADD content_hash AS HASHBYTES('SHA2_256', LEFT(content, 8000)) PERSISTED） - PostgreSQL 可对
TEXT字段建表达式索引：CREATE INDEX idx_posts_content_prefix ON posts ((left(content, 200)));，配合WHERE left(content, 200) LIKE 'error%'实现前缀快速过滤 - 务必定期更新统计信息：
UPDATE STATISTICS table_name WITH FULLSCAN（SQL Server）或VACUUM ANALYZE table_name（PostgreSQL），否则优化器可能低估 LOB 列平均长度，错配内存预算
真正危险的从来不是视图，而是你没看清执行计划里那一行 Heap Fetches: 12489 或 Loose index scan: false —— 它们才是内存悄悄溢出的实时读数。
