自连接视图是将同一张表用两个别名进行LEFT JOIN，从而表达单层父子关系；它通过t1.parent_id = t2.id关联子节点与父节点，显式别名区分字段，支持NULL父节点，但不支持递归，仅适用于固定一级层级结构。
什么是自连接视图，它为什么能表达父子关系
自连接视图本质是把同一张表用两个别名“拉进来”做 JOIN，让行与行之间产生层级关联。比如 categories 表里有 id 和 parent_id，要查出“每个分类的名称 + 它父分类的名称”，就必须让这张表既当子表又当父表。
关键点在于：不能直接在视图定义里写递归逻辑（标准 SQL 视图不支持 WITH RECURSIVE），所以它只适合**单层父子**，比如一级分类和二级分类；多级树形结构得用 CTE 或程序处理。
怎么写一个安全可用的自连接视图
核心是明确连接条件、处理空父节点、避免列名冲突。常见错误是漏掉 LEFT JOIN 导致父节点为空的记录被丢弃，或没给重复字段加别名导致视图创建失败。
- 必须用
LEFT JOIN连接自身，确保子节点即使没有父节点也能保留 - 所有同名字段（如
id、name）必须显式用别名区分，例如t1.name AS category_name和t2.name AS parent_name - 连接条件一定是
t1.parent_id = t2.id，不是反过来——子表的parent_id指向父表的id - 如果原表有索引，建议在
parent_id字段上建索引，否则大表自连接性能会明显下降
示例语句：
CREATE VIEW category_with_parent AS SELECT t1.id AS id, t1.name AS category_name, t1.parent_id AS parent_id, t2.name AS parent_name FROM categories t1 LEFT JOIN categories t2 ON t1.parent_id = t2.id;
查询时为什么查不到父名称？常见坑有哪些
最常遇到的是数据层面问题，而不是语法错误。执行 SELECT * FROM category_with_parent 却发现 parent_name 全是 NULL，大概率是以下原因：
-
parent_id字段存了 0 或 -1 等非法值，但对应id在表中不存在；数据库不会报错，只是JOIN失败 -
parent_id允许为NULL，但业务误填成空字符串''或空格，导致类型不匹配（数值型 vs 字符型） - 视图创建后原表结构变了（比如删了
name字段），但视图没刷新，查询时报column does not exist - 某些数据库（如 MySQL 5.7）默认不支持视图里引用未明确声明的别名，需确认是否开启
sql_mode中的ONLY_FULL_GROUP_BY相关限制
视图 vs 直接写 JOIN 查询，什么时候该选哪个
视图不是银弹。它简化了调用方的 SQL，但牺牲了灵活性和可调试性。
- 适合场景：多个业务模块都要查“分类+父分类”，且字段固定、条件简单（如只加
WHERE t1.status = 1） - 不适合场景：需要动态控制连接深度（如查祖父节点）、带聚合（
COUNT(*)）、或要配合ORDER BY+LIMIT做分页——这时直接写JOIN更可控 - 特别注意：PostgreSQL 的视图默认是“即时计算”，不会缓存结果；SQL Server 的 indexed view 虽然能加速，但要求非常苛刻（如必须用
SCHMABINDING，且不能有LEFT JOIN）
真正容易被忽略的是权限继承——创建视图的用户必须对基表有 SELECT 权限，而调用视图的用户也必须被单独授权，这点在生产环境经常卡住上线。
