缺失索引导致join死锁，因无索引时sql server被迫表扫描并锁全表页，引发循环等待；需为驱动表建覆盖where和join字段的联合索引，被驱动表join列须为索引键，且验证执行计划是否真实使用index seek。
为什么缺失索引会让JOIN直接触发死锁
不是JOIN语法本身危险，而是没索引时SQL Server被迫用表扫描（Table Scan）——它会对整张堆表或聚集索引所有页加锁，哪怕你只改1行。两个并发事务分别执行 UPDATE ... JOIN 且都走扫描，就极易形成“事务1锁了Table1第1页、等Table2第3页，事务2锁了Table2第3页、等Table1第1页”的循环等待。
典型现象：Deadlock encountered ... Deadlock victim 频繁报错，sys.dm_tran_locks 显示大量 resource_type = PAGE 或 KEY 锁，且 request_mode 为 X 或 U，但锁对象集中在同一张表的多个不同页上。
- 驱动表（WHERE所在表）的过滤字段没索引 → 全表扫描 → 锁全表
- 被驱动表（JOIN ON所在表）的连接字段没索引 → 嵌套循环中对每行做查找 → 每次都可能触发页锁升级
- JOIN条件含隐式转换，比如
ON t1.id = t2.uid但t1.id是INT、t2.uid是VARCHAR→ 索引完全失效 → 回退到扫描
哪些索引必须立刻补上
重点不是“建索引”，而是让JOIN路径可预测、锁范围最小。关键索引要覆盖驱动表的WHERE条件 + 被驱动表的JOIN条件，且避免回表。
- 驱动表：建联合索引，把
WHERE字段放最左，JOIN字段紧随其后。例如UPDATE o SET status=1 FROM orders o JOIN customers c ON o.customer_id = c.id WHERE o.created_at > '2024-01-01'→ 必须有orders(created_at, customer_id) - 被驱动表：JOIN列必须是索引键，优先用主键；若WHERE里还有条件（如
c.region = 'CN'），建customers(region, id)而非单列region索引，避免额外键查找 - 禁止在JOIN条件里用函数，如
ON UPPER(t1.name) = t2.name—— 这会让两边索引全部失效
如何验证索引真起作用了
别只看“有没有建”，要看执行计划是否真的用了索引Seek而不是Scan。同一SQL在不同数据量下行为可能突变，必须实测。
- 用
SET STATISTICS XML ON执行你的JOIN语句，看执行计划里<relop></relop>节点的PhysicalOp是Index Seek还是Index Scan或Table Scan - 检查
EstimatedRows和ActualRows是否接近；如果相差10倍以上，说明统计信息过期，运行UPDATE STATISTICS再试 - 在
sys.dm_exec_query_stats中查该SQL的last_logical_reads：加索引后应明显下降（比如从几万降到几十）
临时绕过但不能长期依赖的手段
索引上线前，业务不能停。但以下操作只是“止血”，不是根治，用完得撤。
- 在UPDATE语句开头加
SELECT TOP 1 * FROM table WITH (UPDLOCK, HOLDLOCK) WHERE ...，提前按确定顺序锁住关键行，强制统一加锁起点 - 启用
READ_COMMITTED_SNAPSHOT（ALTER DATABASE YourDB SET READ_COMMITTED_SNAPSHOT ON），能消除读写冲突，但写-写冲突仍在，且tempdb压力会上升 - 绝对不要用
WITH(NOLOCK)解决死锁——它跳过锁，但换来的是脏读，订单、库存类逻辑会直接出错
最易被忽略的一点：索引建完不等于问题消失。如果JOIN涉及多层视图嵌套，或查询里混用了参数化和字面量，优化器仍可能选错执行路径。上线后必须用真实并发流量压测，盯着 sys.dm_os_waiting_tasks 里的 wait_type = LCK_M_X 是否收敛。
