自连接视图易吃内存，因双重数据加载、全索引扫描致缓冲池溢出；SELECT * 加剧大字段复制；需显式列、索引优化、WHERE下推、禁用NOLOCK，并优先用CTE或索引视图替代。
自连接视图为什么容易吃内存
自连接视图（比如 CREATE VIEW v_emp_mgr AS SELECT e1.name, e2.name AS mgr_name FROM employees e1 JOIN employees e2 ON e1.manager_id = e2.id）在查询时可能触发双重数据加载：优化器无法预判是否能复用缓存页，导致同一张表的两份副本同时驻留缓冲池。尤其当基表本身已占大量内存（如千万级员工表），视图未加过滤条件时，SQL Server 或 MySQL 的执行计划常退化为嵌套循环 + 全索引扫描，中间结果集直接撑爆 tempdb 或 InnoDB 的 buffer_pool。
避免 SELECT * 和冗余字段
视图定义里写 SELECT * 是内存杀手——它强制加载所有列（含 TEXT、BLOB、JSON 等大字段），即使上层查询只取 2 列。更糟的是，自连接会让这些大字段被复制两份。
- 只显式列出下游真正需要的字段，例如
SELECT e1.id, e1.name, e2.name AS mgr_name - 确认连接字段（如
manager_id、id）已有索引；缺失时自连接会触发全表扫描 × 2 - 若需关联层级（如“经理的经理”），优先用 CTE 递归替代多层自连接视图，避免编译期爆炸式膨胀
WHERE 条件必须下推到视图定义中
很多人把视图当黑盒，外部再加 WHERE dept_id = 5，但优化器未必能把该条件“穿透”进自连接内部，结果先算出全部员工-经理组合，再过滤——中间结果可能达亿级行。
- 在视图定义中直接固化高频过滤项，例如：
CREATE VIEW v_emp_mgr_dept5 AS SELECT ... FROM employees e1 JOIN employees e2 ... WHERE e1.dept_id = 5 - 若需动态部门，改用带参数的内联表值函数（TVF），SQL Server 支持
WHERE下推，MySQL 可用PREPARE+EXECUTE模拟 - 禁用
NOLOCK或READ UNCOMMITTED在视图里——它虽减少锁开销，但会干扰缓冲区管理策略，反而增加脏页刷盘压力
用物化方式替代逻辑视图（仅限 SQL Server）
SQL Server 不支持原生物化视图，但可用索引视图（Indexed View）强制固化结果。前提是满足严格条件：视图必须是确定性的、不能含 GETDATE() 等非确定函数、所有连接必须用 INNER JOIN、且基表需有唯一聚集索引。
- 创建带唯一聚集索引的视图后，SQL Server 会把连接结果物理存储，并自动维护一致性
- 内存占用从“每次查询都重算”变成“仅维护增量变更”，对读多写少场景极有效
- 注意：启用
SET NUMERIC_ROUNDABORT OFF和ANSI_NULLS ON等会话级选项，否则建索引会失败
真实环境里，最容易被忽略的是视图嵌套——比如在另一个视图里引用这个自连接视图，再套一层聚合。这时执行计划里可能看不到原始表名，只看到 Expr1001 这类代号，根本没法判断哪一步在吃内存。务必用 SET STATISTICS XML ON 抓实际执行计划，盯紧 EstimateRows 和 Storage 节点。
