视图本身不会导致死锁，真正引发死锁的是其底层表在并发更新时的加锁冲突；解决方向应聚焦表索引优化、统一访问顺序及缩短事务持有时间，而非修改视图定义。
视图本身不会导致死锁，真正引发死锁的是视图背后 SELECT 所依赖的底层表在并发更新时的加锁冲突。解决方向必须落在表结构、访问顺序和事务控制上，而不是改写视图定义。
为什么视图查询会卷入死锁
SQL Server 或 MySQL 中的视图只是保存的 SELECT 语句，执行时会被展开为对基表的实际访问。当多个事务通过视图读取数据（尤其是带 JOIN、ORDER BY、WHERE 条件的复杂视图），同时又有其他事务在修改这些基表——特别是以不同顺序更新同一组主键或索引键时，就极易触发循环等待。
典型诱因包括：
- 视图中
JOIN多张表，而各事务更新这些表的顺序不一致（如事务A先更新orders再更新order_items，事务B反过来） - 视图含
WHERE条件但对应字段无索引，导致 UPDATE/SELECT 扫描全表或大范围加锁（InnoDB 的间隙锁、SQL Server 的键范围锁） - 应用层用视图做“读已提交”查询，却在长事务中嵌套调用它，延长了对底层表资源的持有时间
优化底层表索引：让锁更精准、更短暂
缺失索引是放大死锁概率的隐形推手。不是所有 WHERE 字段都适合建索引，但以下三类必须覆盖：
- 视图中
JOIN条件字段（如orders.user_id = users.id→orders.user_id和users.id都要有索引） - 视图中
WHERE过滤字段（如WHERE status IN ('pending', 'processing')→ 在status上建非聚集索引） - 视图中
ORDER BY字段（避免排序时额外加锁；若常按created_at DESC查询，考虑倒序索引或包含列）
特别注意：SQL Server 中，如果视图含 SELECT * FROM t1 JOIN t2，而 t2 上只有 id 主键，但 JOIN 实际走的是 t2.code 字段，则必须给 code 加索引，否则可能触发表锁升级。
减少长事务：切断锁持有链的关键动作
视图被调用本身不危险，危险的是它出现在一个持续数秒甚至数十秒的事务里。常见高危模式：
- 在事务内调用视图查出结果后，再做 HTTP 请求、文件写入、复杂计算等耗时操作
- 用视图做分页查询（
OFFSET ... FETCH），但未加NOLOCK或未限定时间窗口，导致扫描大量历史数据并持锁 - ORM 框架自动生成的“读+写”混合事务，其中读部分恰好命中某个复杂视图
对策很直接：
- 把视图查询移出事务体，只保留真正需要原子性的写操作
- 如必须在事务中读，优先用
WITH (NOLOCK)（SQL Server）或READ UNCOMMITTED隔离级别（注意脏读风险） - 避免在事务中执行带聚合、子查询、多层嵌套的视图；拆成简单
SELECT+ 应用层组装
最容易被忽略的点：视图调用方的事务边界不清晰
很多团队花大力气优化视图性能和索引，却没意识到：死锁日志里显示的“阻塞源头”往往是某段 C# 或 Java 代码开启了一个隐式事务，并在调用视图后迟迟不 COMMIT。尤其在使用 Entity Framework 的 SaveChanges 或 Spring 的 @Transactional 时，事务生命周期由框架自动管理，容易超出预期。
验证方式很简单：在 SQL Server 中运行 SELECT * FROM sys.dm_tran_active_transactions，看是否存在 transaction_begin_time 超过 5 秒仍未结束的事务；MySQL 则查 SHOW ENGINE INNODB STATUS 中的 TRANSACTIONS 部分。
