视图嵌套过深本身不直接导致死锁，但会使底层表加锁行为不可控；SQL Server超10层即报Msg 319，属解析器硬编码限制，无法通过配置绕过，需用CTE扁平化或物化中间结果来规避。
视图嵌套过深本身不会直接导致死锁，但会让底层表的加锁行为更不可控——真正出问题的是多层视图展开后，不同事务对同一组基表以不一致顺序加锁，再叠加长事务或缺失索引，死锁概率就指数级上升。
SQL Server 视图嵌套超10层直接报错 Msg 319，怎么绕过去？
这不是配置能调的限制，是解析器硬编码的保护机制。一旦触发，查询连编译都失败，根本走不到执行和加锁阶段。
- 别试图用
sp_configure或注册表改上限——SQL Server 没提供这个开关 - 用
sys.dm_exec_query_plan+ XML 搜索ViewName可估算当前视图链深度，超过 7 层就得预警 - 扁平化最可靠：把中间层视图定义（比如
v4）直接抄进上层CREATE VIEW v5 AS WITH ... SELECT ... FROM (...) AS v4_sub，用 CTE 替代一层SELECT * FROM v4 - 物化中间结果更治本：对读多写少的聚合层（如日报统计），用
SELECT INTO #temp或定时刷入分区表，彻底切断视图依赖链
PostgreSQL/MySQL 中深层嵌套不报错，为啥反而更容易死锁？
不报错 ≠ 安全。它们只是延迟校验或惰性展开，但执行时照样会把所有嵌套视图“拍平”成一张大查询，锁行为完全暴露在最终执行计划里。
- PostgreSQL 在
EXPLAIN ANALYZE里能看到实际扫描的基表顺序；如果某层视图含ORDER BY但没索引，优化器可能先物化全部中间结果再排序——等于提前锁住几千行 - MySQL 8.0+ 的
optimizer_trace开启后，在resolve_invisible_columns阶段卡住，往往是因为某层视图的JOIN条件字段没索引，导致元数据解析反复失败 - 关键陷阱：
CREATE VIEW v2 AS SELECT * FROM v1看似无害，但如果v1含GROUP BY user_id，而v2又被用于UPDATE t SET x=(SELECT y FROM v2 WHERE id=t.id)，InnoDB 就会对整个v1的分组结果集加临键锁
如何让嵌套视图下的 UPDATE 不再随机死锁？
核心不是压扁视图，而是控制它展开后的物理执行路径——让所有事务按同一顺序访问行，并且只锁真正需要的行。
- 禁止在事务里直接跑
UPDATE ... WHERE id IN (SELECT id FROM huge_view)；先用窄查询SELECT id FROM huge_view WHERE status='pending' ORDER BY id LIMIT 100（确保status有索引），再拼IN (1,2,3...)批量更新 - 把视图逻辑重写为显式
JOIN：例如原语句UPDATE orders SET processed=1 WHERE id IN (SELECT order_id FROM v_user_orders WHERE user_type='vip')，改成UPDATE orders o JOIN v_user_orders u ON o.id = u.order_id SET o.processed=1 WHERE u.user_type='vip'，并确认u.user_type和o.id都有索引 - 在 SQL Server 中，给关键视图加
WITH (NOLOCK)是饮鸩止渴——它可能让 UPDATE 读到脏数据，进而更新错误行；真要降锁冲突，该设READ COMMITTED SNAPSHOT数据库级选项
最常被忽略的一点：视图嵌套越深，EXPLAIN 输出里越难一眼看出哪张基表在被全表扫描。别只盯着顶层视图名，得逐层展开看每个 FROM 子句实际走的索引——没索引的那张表，就是死锁风暴的中心。
