innodb高并发写入性能优于myisam的根本原因是行级锁降低资源竞争粒度，但仅当sql走索引、开启事务且隔离级别合理时生效；否则行锁退化为表锁，实际并发能力接近甚至低于myisam。
InnoDB在高并发写入场景下性能远超MyISAM，根本不在“引擎更先进”，而在于它能把锁粒度压到单行——但这个优势只在你写出能触发行级锁的SQL时才生效；否则实际表现可能比MyISAM还差。
行级锁只在走索引时真正生效
InnoDB的“行锁”本质是加在索引记录上的锁，不是物理行。如果WHERE条件没命中索引（比如LIKE '%abc'、NOT IN、隐式类型转换），InnoDB会退化为全表扫描+逐行加锁，效果等同于表锁。
- 主键等值查询：
WHERE id = 100→ 只锁1行（Record Lock） - 普通索引范围查询：
WHERE status = 1→ 锁所有匹配索引项，含间隙（Next-Key Lock） - 无索引字段查询：
WHERE remark LIKE '%test%'→ 全表扫描，每行都尝试加锁 → 并发能力接近MyISAM
MyISAM的表级锁在并发写入时立刻卡死
MyISAM对任何INSERT/UPDATE/DELETE都直接申请整张表的WRITE LOCK，期间所有其他写请求排队，读请求也被阻塞（除非启用concurrent_insert且仅限尾部追加）。
- 两个事务分别更新
id=1和id=10000→ 仍互相等待 - 一个慢
SELECT正在执行 → 所有写操作必须等它结束 - 没有事务回滚能力，写中断后表可能处于中间状态，需人工
REPAIR TABLE
InnoDB的并发优势依赖事务与隔离级别配合
行锁不是自动生效的开关，它需要事务开启 + 合理隔离级别 + 正确使用方式才能协同工作：
-
autocommit=1（默认）下，每个SQL都是独立事务 → redo日志频繁刷盘，吞吐打折 - 高频更新同一字段（如
status）→ 即使走索引，也可能因热点行争用引发大量Lock wait timeout exceeded -
innodb_lock_wait_timeout默认50秒，线上建议调低至5~10秒，避免无限等待掩盖真实问题 - 批量写入应显式用
BEGIN; ... ; COMMIT包裹，控制事务大小（≤ 5000 行），避免undo日志暴涨
别只看ENGINE=InnoDB就以为高并发自动达成
真正决定并发表现的是SQL实际触发的锁行为，不是建表语句里写的引擎名。很多“InnoDB变慢”的案例，根源是：
-
EXPLAIN显示type=ALL（全表扫描），但开发者误以为走了索引 -
WHERE DATE(create_time) = '2026-05-11'这类函数用法导致索引失效 - 未调优
innodb_flush_log_at_trx_commit，批量导入仍用默认值1，白白牺牲吞吐 - 高频写表堆了七八个二级索引 → 每次写入都要更新所有索引树，开销成倍放大
最常被忽略的一点：InnoDB的间隙锁（Gap Lock）在REPEATABLE READ下默认启用，会锁住不存在的“间隙”，防止幻读——但也可能意外阻塞本不该冲突的插入，这点连EXPLAIN都看不到，只能靠INFORMATION_SCHEMA.INNODB_TRX和死锁日志排查。
