视图查询卡住时应优先排查底层表锁，PostgreSQL用pg_locks与pg_stat_activity定位阻塞会话及锁对象，SQL Server用sys.dm_tran_locks与sys.dm_exec_requests查阻塞链，MySQL则查performance_schema.data_lock_waits；视图本身不持锁，锁必源于其基表的DML或未提交事务。

视图查询卡住时怎么快速定位是底层表被锁了

直接查 pg_locks 和 pg_stat_activity（PostgreSQL）或 sys.dm_tran_locks + sys.dm_exec_sessions（SQL Server）最有效。别先看视图定义，先确认是不是锁等待在作祟。

• PostgreSQL：运行 SELECT blocked_pid, pid, query FROM pg_stat_activity WHERE blocked_pid IS NOT NULL; 找出被阻塞的会话，再用 blocked_pid 关联 pg_locks 查锁对象
• SQL Server：执行 SELECT * FROM sys.dm_exec_requests WHERE blocking_session_id 0;，然后用 blocking_session_id 去查 sys.dm_exec_sql_text 看阻塞源头的语句
• MySQL（8.0+）：查 performance_schema.data_lock_waits，注意它只记录 InnoDB 层的锁等待，且默认可能未启用相关 instrument

关键点：视图本身不持锁，锁一定来自它的 SELECT 涉及的基表——所以看到视图查询慢，第一反应不是改视图，而是查它依赖的表有没有 DML 正在长时间执行或事务没提交。

创建视图时如何避免隐式锁升级（特别是 SQL Server）

SQL Server 的视图如果带 NOLOCK 提示或使用 READ UNCOMMITTED 隔离级别，确实能绕过共享锁，但代价是脏读。更稳妥的做法是控制访问模式而非盲目加提示。

• 避免在视图定义里写 SELECT * FROM t WITH (NOLOCK) —— 这会让所有调用该视图的地方都继承这个风险，且无法被调用方覆盖
• 把锁行为交给调用方控制：视图保持中性（不带任何 hint），让上层应用在 SELECT FROM my_view 时按需加 WITH (NOLOCK) 或切换隔离级别
• 慎用 SCHEMABINDING：它会让视图绑定到具体列结构，虽然提升性能，但也导致修改基表结构时必须先删视图——这期间可能引发部署窗口的锁争用

本质问题：视图不是独立实体，它的锁行为完全由底层查询计划和事务上下文决定。所谓“视图被锁”，其实是执行计划在打开基表时申请锁失败。

PostgreSQL 中物化视图刷新卡住，怎么解而不中断业务

PG 的 REFRESH MATERIALIZED VIEW CONCURRENTLY 是唯一不锁读的方案，但要求原物化视图有唯一索引（通常是主键或含唯一约束的列）。没建索引？刷新就会退化为全表锁。

• 检查是否已有唯一索引：\d+ my_matview，看输出里是否有 Unique index
• 如果没有，先加索引：CREATE UNIQUE INDEX ON my_matview (id);（确保 id 在源查询中是确定且非空的）
• 强制刷新前，用 SELECT pg_blocking_pids(pid) FROM pg_stat_activity WHERE datname = current_database() AND application_name = 'refresh_matview'; 确认没其他刷新进程在跑

注意：CONCURRENTLY 刷新仍会拿 SHARE UPDATE EXCLUSIVE 锁，不影响普通 SELECT，但会阻塞其他 CONCURRENTLY 刷新、DROP、ALTER 等 DDL —— 这些操作容易被忽略，却正是线上突然卡住的常见原因。

MySQL 视图查询慢且 show processlist 显示 Waiting for table metadata lock

这不是数据锁，是元数据锁（MDL），通常因为对视图依赖的某张表正在执行 ALTER TABLE、DROP INDEX 或长事务里的 DML。视图查询本身虽轻量，但需要先获取基表的 MDL 才能解析执行计划。

• 查谁占着 MDL：SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_TYPE = 'TABLE' AND LOCK_STATUS = 'PENDING';
• 关联 performance_schema.threads 找出对应线程的 PROCESSLIST_ID，再查 information_schema.PROCESSLIST 看它在干什么
• 临时解法：杀掉持有 MDL 的长事务（KILL [id]），但要确认它不是关键批处理；长期解法是在低峰期做 DDL，并用 ALGORITHM=INSTANT（8.0.12+）减少锁表时间

最容易被忽略的一点：视图定义里如果用了子查询或 UNION，MySQL 可能会在优化阶段多次访问同一张基表的元数据——这意味着单个视图查询可能触发多次 MDL 申请，放大阻塞概率。