先抛一个数据库开发中常遇到的“天花板”：SQL Server 视图嵌套超过32层，直接报Msg 319；MySQL默认卡在31层就拒绝解析；PostgreSQL虽然不报错，但5–7层后执行计划经常失控。这不是少数人的偶然遭遇，而是数据库引擎在解析阶段就埋下的硬性限制——下面这张图可能让你更有体感。
一句话总结：限制确实存在，而且每个数据库的处理方式都像“各有各的脾气”。
SQL Server 视图嵌套为什么到第 33 层就崩？
这可不是什么配置参数没调够或者服务器资源吃紧的问题。SQL Server的解析器在绑定（binding）阶段主动终止递归——它直接把32层写死在代码里了。每展开一层视图，引擎都要重建逻辑树、校验元数据、检查依赖关系，到第33层时，它二话不说抛出Msg 319, Level 15, State 1，编译就此中断。
sp_depends已弃用，用它查不到真实的视图链长度；sys.dm_exec_describe_first_result_set只能看到最终结果集，中间嵌套过程压根不反映。- 视图 A → B → C → D → … → Z 这种链式引用，只要累计调用深度 ≥33（哪怕全是视图），就触发错误。
- 别以为CTE的非递归部分就不算——比如
WITH v1 AS (...), v2 AS (SELECT * FROM v1)这种写法也计入那32层。 - 索引视图更严格：只能引用其他索引视图，而且依赖链一改，底层索引可能隐式失效，排查起来特别隐蔽。
MySQL 和 PostgreSQL 怎么“悄悄处理”深层嵌套？
它们不靠报错来直接拦截，而是用性能退化或解析截断倒逼你重构。本质上是一种“沉默的惩罚”。
- MySQL 在
PREPARE阶段就用递归栈深度判断，超过31层直接报ERROR 1235，连EXPLAIN都看不到——语句根本没进优化器。 - PostgreSQL 允许任意层数，但一旦嵌套 ≥5 层，优化器大概率放弃代价估算，强制
Materialize中间结果，Actual Rows暴涨十倍以上，查询从毫秒级直接掉到秒级。 - 两者都对
ORDER BY或LIMIT非常敏感：嵌套层里只要有一处加了这两个，外层条件基本无法下推到基表，索引等于摆设。
怎么快速确认当前视图链到底嵌了几层？
别靠猜，动手查。人工追溯往往比依赖系统的依赖视图更靠谱。
- SQL Server：运行
sp_refreshview 'your_top_view'后，用OBJECT_DEFINITION逐层展开。比如执行SELECT OBJECT_DEFINITION(OBJECT_ID('v2'))看它是否引用v1，一直查到找不到上游视图为止。 - PostgreSQL：查
pg_depend要配合pg_class和pg_attribute手动拼路径。更简单的办法是开启log_min_duration_statement = 0，抓慢查询的EXPLAIN ANALYZE，数Materialize节点的嵌套深度。 - 通用陷阱：别信
SELECT * FROM v_deep跑得通就等于没问题——可能只是缓存了旧计划，一清缓存或改参数就崩。
真正麻烦的往往不是“能不能到第4层”，而是改了某一行字段名或加了一个WHERE条件后，你没法快速判断它还走不走索引、会不会漏数据、执行时间会不会翻十倍。三层之后，多数数据库已经把这一部分的逻辑交给了概率和运气——所以，嵌套深度尽早评估，别等到线上翻车才回头查。
