根本原因是SQL Server将级联删除链路塞入单事务执行，且子表外键列缺失索引时会触发全表扫描并加意向排他锁（IX），导致整表阻塞；应改用TOP分批删除而非禁用级联。
SQL Server中ON DELETE CASCADE为什么会锁整张表？
根本原因不是级联逻辑本身，而是SQL Server把整个级联链路塞进单个事务里执行。比如删1条customers记录，触发删5000条orders和2万条order_details，这没问题；但若WHERE条件匹配10万条customers，事务就会持续数分钟——期间customers、orders、order_details三张表的索引页、数据页全被持锁，其他查询/更新全部阻塞。
更隐蔽的是：即使你只删1行，只要子表外键列（如orders.customer_id）没建索引，SQL Server在查找关联记录时会强制全表扫描，对整张orders加意向排他锁（IX），等同于锁表。
禁用ON DELETE CASCADE不是解法，分批才是关键
保留外键定义（含ON DELETE CASCADE），但绝不让它一次性处理大批量主表记录。改用带TOP的循环删除，让每批次都在毫秒级完成：
WHILE 1=1
BEGIN
DELETE TOP (5000) FROM customers
WHERE created_date < '2020-01-01';
IF @@ROWCOUNT = 0 BREAK;
WAITFOR DELAY '00:00:00.1';
END
必须满足的条件：
-
created_date字段要有索引，否则TOP无法高效定位 - 每次删完后加
WAITFOR DELAY，给日志写入和锁释放留出缓冲时间 - 避免在高峰期执行，尤其不能与大报表查询共用同一时段
联表DELETE比级联更可控，但语法容易写错
SQL Server不支持MySQL那种DELETE t1 FROM t1 JOIN t2写法，正确格式是：
DELETE t1 FROM customers t1 INNER JOIN orders t2 ON t1.id = t2.customer_id WHERE t2.status = 'cancelled';
这种写法的好处是：只锁涉及的customers和orders行，不会波及order_details；缺点是必须手动写出所有关联逻辑，且WHERE条件必须落在JOIN后的结果集上。常见错误包括：
- 漏写
DELETE t1中的别名，导致删错表 - WHERE条件误写成
t1.status（该字段不存在），语句静默失败 - JOIN未加索引字段，引发嵌套循环+全表扫描
真正容易被忽略的点：子表外键索引缺失
哪怕你已禁用ON DELETE CASCADE，只要子表外键列（如orders.customer_id）没建索引，任何基于该字段的DELETE或JOIN都会卡死。验证方法：
SELECT name FROM sys.indexes
WHERE object_id = OBJECT_ID('orders')
AND index_id IN (
SELECT index_id FROM sys.index_columns
WHERE object_id = OBJECT_ID('orders')
AND column_id = COLUMNPROPERTY(OBJECT_ID('orders'), 'customer_id', 'ColumnId')
);
如果查不到结果，立刻补索引：CREATE INDEX IX_orders_customer_id ON orders(customer_id);。没有这步，其他所有优化都是空中楼阁。
