视图本身不加锁，锁竞争根源在底层表的访问方式和事务上下文；必须从执行计划、索引覆盖和事务边界三处入手，改视图定义几乎无效。
视图本身不加锁，锁竞争根源在底层表的访问方式和事务上下文——改视图定义几乎没用，必须从执行计划、索引覆盖和事务边界三处动手。
怎么看视图实际执行时锁了哪些资源
视图只是语法糖，SELECT * FROM my_view 会完全展开为对基表的真实查询。真正持锁的是展开后的 SQL，不是视图名。关键要捕获它实际走的执行路径：
- SQL Server：打开
SET STATISTICS XML ON，执行视图查询，看执行计划里是否出现Table Scan或Clustered Index Scan；有就说明可能申请大量 S 锁 - MySQL：用
EXPLAIN FORMAT=TREE或EXPLAIN ANALYZE（8.0.21+），重点盯rows_examined和是否用上索引；若显示Using where; Using filesort，大概率在排序阶段持锁时间拉长 - PostgreSQL：开
EXPLAIN (ANALYZE, BUFFERS)，观察Shared Hit/Read和Rows Removed by Filter—— 后者越高，越可能因过滤无索引字段导致锁膨胀
哪些字段没索引，视图就容易卷入死锁
不是所有 WHERE 字段都该建索引，但以下三类不覆盖，锁冲突概率陡增：
-
JOIN条件字段：如orders.status_id = status.id→orders.status_id必须有索引（status.id通常已有主键） -
WHERE过滤字段：如WHERE created_at > '2026-06-01'→ 单独建created_at索引效果有限，优先建复合索引(status, created_at)（如果常查status = 'pending'） -
ORDER BY字段：如视图含ORDER BY updated_at DESC LIMIT 20→ 建倒序索引CREATE INDEX idx_updated_desc ON table_name (updated_at DESC)，避免排序阶段全量持锁
事务里调用视图是最危险的使用场景
视图查询耗时 50ms 并不可怕，可怕的是它嵌在一个持续 3 秒的事务里。典型高危模式：
- 先
SELECT FROM view查出订单列表，再发 HTTP 请求通知下游，最后才COMMIT - 分页查询写成
SELECT * FROM view ORDER BY id OFFSET 10000 ROWS FETCH NEXT 20 ROWS ONLY，未加时间过滤，扫描历史百万行并全程持 S 锁 - ORM 自动生成的“读+写”混合事务，读部分命中复杂视图，写部分更新同一张表（比如视图 JOIN 了
users，事务末尾又UPDATE users）
对策非常直接：把视图查询移出事务体，只保留真正需要原子性的写操作。
怎么确认阻塞源是不是视图引发的
别只盯着报错 SQL，得顺藤摸瓜找真正持锁的人：
- MySQL：查
information_schema.INNODB_TRX找trx_state = 'LOCK WAIT'的事务，再关联INNODB_LOCK_WAITS得到blocking_trx_id，最后查该 ID 对应的trx_query—— 它才是源头，哪怕它是一条简单的UPDATE - SQL Server：用
sys.dm_exec_requests筛出blocking_session_id > 0的会话，再通过session_id关联sys.dm_exec_sql_text，看被阻塞的语句是否来自视图展开后的某段 JOIN - GBase 8c / PostgreSQL：优先查
pg_stat_activity中状态为idle in transaction的会话，它的backend_start和xact_start时间差越大，越可能是长期持锁的元凶
最容易被忽略的是：视图里用了 SELECT * + 多表 JOIN，而其中一张表只在 id 有主键，但实际 JOIN 走的是 code 字段 —— 此时 code 缺索引，就会触发锁升级，整张表被扫，其他事务全卡住。
