InnoDB高并发优势源于行级锁替代MyISAM表级锁，但前提是SQL必须走索引、开启事务且隔离级别合理；否则行锁退化为表锁，失去并发优势。
MySQL InnoDB 在高并发下优于 MyISAM，核心原因不是“InnoDB 更先进”，而是它用 行级锁 替代了 MyISAM 的 表级锁，直接降低了写操作间的资源竞争粒度。但这个优势有严格前提：必须走索引、事务开启、隔离级别合理——否则行级锁会退化为表级效果。
行级锁只在命中索引时生效
InnoDB 的 行级锁 实际加在索引项上，不是物理行。如果 WHERE 条件没走索引（比如 LIKE '%abc'、NOT IN、字段类型隐式转换），InnoDB 会退化为全表扫描 + 表级锁（准确说是意向排他锁 IX 配合大量记录锁，效果等同锁表）。
- 主键或唯一索引等值查询（
WHERE id = 100）→ 只锁单行（Record Lock） - 普通索引范围查询（
WHERE status = 1）→ 锁所有匹配的索引项，可能包含间隙（Next-Key Lock） - 无索引字段查询（
WHERE remark LIKE '%test%'）→ 全表扫描，每行都尝试加锁 → 实际并发能力接近 MyISAM
MyISAM 的表级锁在写场景下立刻暴露瓶颈
MyISAM 对任何 UPDATE/DELETE 都直接申请整张表的写锁（WRITE LOCK），期间所有其他写请求排队，读请求也被阻塞（除非启用并发插入）。这意味着：
- 哪怕两个事务更新的是完全不重叠的两行（如
id=1和id=10000），也会互相等待 -
INSERT并发受限于concurrent_insert配置，且仅对尾部追加有效 - 没有事务支持，崩溃后只能靠
REPAIR TABLE，无法保证部分成功状态
InnoDB 行锁的代价常被低估
行级锁不是免费午餐。它带来更高内存占用（每个锁对象需维护）、更慢的加锁速度、以及真实存在的死锁风险：
- 锁信息存在内存中（
INFORMATION_SCHEMA.INNODB_TRX、INNODB_LOCKS可查），高并发下锁管理开销明显 - 死锁检测由
INFORMATION_SCHEMA.INNODB_METRICS中的lock_deadlocks计数器暴露，一旦频繁出现，说明业务逻辑存在锁顺序混乱 - 间隙锁（
Gap Lock）和临键锁（Next-Key Lock）在可重复读（REPEATABLE READ）下默认启用，会锁住不存在的“间隙”，防止幻读——但也可能意外阻塞本不该冲突的插入
真正决定并发表现的是锁行为，不是引擎名
别只看 ENGINE=InnoDB 就以为自动获得高并发。关键看实际 SQL 是否触发了预期的锁类型：
- 用
SELECT ... FOR UPDATE或UPDATE前，先EXPLAIN确认type是const/ref，不是ALL - 避免在 WHERE 条件中对索引列使用函数（如
WHERE DATE(create_time) = '2026-05-11'），会导致索引失效 - 批量更新尽量拆成小事务，减少单次持有锁的时间，而不是堆大事务
- 监控
Innodb_row_lock_waits和Innodb_row_lock_time_avg这两个状态变量，它们比“引擎选型”更能反映真实锁压力
行级锁的优势，永远绑定在“精准索引访问”和“合理事务边界”之上。脱离这两点谈 InnoDB 并发，就像谈跑车性能却不踩油门。
