行锁升级为表锁是数据库资源压力下的主动权衡，sql server可配置升级阈值与策略，mysql无真正锁升级机制，其“锁表”源于索引失效或显式锁表，避免关键在优化索引与控制加锁范围。
行锁升级为表锁不是故障，而是数据库在资源压力下主动做的权衡。核心在于：它不按固定路径发生，也不必然逐级推进，更不是所有数据库都采用同一逻辑。
SQL Server 的锁升级是可配置的优化行为
SQL Server 默认在单个事务对一张表持有超过 5000 个行锁或页锁时，可能发起锁升级请求。但是否真正升到表锁，取决于几个关键因素：
- 表上是否有其他阻塞中的锁（有冲突时可能延迟升级）
- ALLOW_ROW_LOCKS 和 ALLOW_PAGE_LOCKS 是否启用（禁用其一将切断对应路径）
- 表级选项 LOCK_ESCALATION 的设置：
• DISABLE：彻底禁用升级（慎用，易导致内存耗尽）
• TABLE：跳过页锁，直接升为表锁
• AUTO：若表已分区，优先升到分区级，提升并发性
MySQL 没有真正意义上的“锁升级”机制
InnoDB 不会像 SQL Server 那样自动合并行锁。所谓“锁表”，其实是以下情况的自然结果：
- WHERE 条件未命中索引 → 全表扫描 → 每行都加行锁 → 锁数量爆炸，极易引发死锁或被优化器拒绝执行
- 模糊查询（如 LIKE '%abc'）、函数包裹字段（如 UPPER(col)）导致索引失效
- 显式执行 LOCK TABLES t WRITE → 直接获得表锁，与行锁无关
- 在 RR 隔离级别下，全扫描还会触发间隙锁+临键锁组合，覆盖整个索引范围，效果等同于锁表
如何避免意外升到表锁
本质是控制加锁范围和减少锁数量，而不是对抗“升级”本身：
- 确保 DML 的 WHERE 字段有高效索引，注意最左前缀、类型隐式转换问题
- 用 EXPLAIN 确认执行计划：type 字段不能是 ALL 或无过滤的 index
- 大表更新/删除务必带 LIMIT，或拆成小范围分批处理（如 id BETWEEN 1000 AND 1099）
- 避免在事务中执行全表扫描类操作；高并发场景下，宁可加缓存也别依赖锁来保一致
意向锁不是升级中间态，而是协调桥梁
IS（意向共享锁）和 IX（意向排他锁）是表级元数据锁，作用是快速判断“这张表里有没有人正在锁行”。它不阻塞读写，也不参与升级流程。当事务给某行加 X 锁时，必须先申请 IX 锁；其他事务想对整表加 X 锁，只需检查是否存在 IX，而不用遍历所有行锁。
