高并发写入必须用InnoDB，因其行级锁、事务和崩溃恢复能力是OLTP唯一可靠底座；MyISAM表级锁致并发写入卡死；InnoDB行级锁生效需走索引，否则退化为全表锁。
高并发场景下必须用 InnoDB，MyISAM 或 Memory 引擎在写多时会直接卡死。这不是权衡选项，而是硬性前提——InnoDB 的行级锁、事务支持和崩溃恢复能力，是 OLTP 类业务唯一能扛住持续写入的底座。
为什么 MyISAM 在高并发写入时不可用
MyISAM 只支持表级锁，UPDATE 或 INSERT 会锁整张表。哪怕只更新一行，其他所有对该表的读写请求都得排队。实际压测中，10+ 并发写入就可能让响应延迟飙升到秒级；一旦出现慢查询或长事务，整个表就“挂起”。它适合静态报表类只读场景，比如归档日志的统计视图，但绝不该出现在订单、库存、账户余额等核心表中。
常见错误现象包括：
- 监控看到
Table_locks_waited指标持续上升 - 执行
SHOW PROCESSLIST时大量线程状态为Locked - 同一张表的
SELECT和UPDATE交替变慢，无明显慢 SQL 却整体吞吐骤降
InnoDB 行级锁生效的前提是走索引
InnoDB 的“行级”不是魔法，它只对索引记录加锁。如果查询没命中索引，就会退化为全表扫描 + 临键锁（next-key lock），效果等同于表锁。例如：
SELECT * FROM orders WHERE status = 'paid' FOR UPDATE;
若 status 列没建索引，InnoDB 会扫描聚簇索引每一行，并对每个扫描页加锁——此时并发更新任意 orders 行都会被阻塞。
确保行级锁真正生效的关键动作：
- 用
EXPLAIN检查执行计划，type字段必须是const、eq_ref、ref或range，绝不能是ALL或index - 高频
FOR UPDATE查询字段优先建唯一索引（如order_no）；若必须用非唯一字段（如user_id），至少建二级索引并组合常用过滤条件（如(user_id, status)） - 避免在 WHERE 中对索引列做函数操作，
WHERE DATE(created_at) = '2026-04-12'会让索引完全失效
减少锁等待时间的实操要点
锁等待不是靠“选对引擎”就能解决的，它取决于事务结构、SQL 写法和隔离级别协同作用：
- 把
SELECT ... FOR UPDATE尽量靠近后续的UPDATE，中间别穿插 HTTP 调用、日志打印、复杂计算等耗时操作——锁从加上的那一刻起，就一直持有到COMMIT - 在允许脏读风险可控的前提下，将隔离级别从默认的
REPEATABLE READ改为READ COMMITTED：它关闭间隙锁，大幅缩小锁范围，且 MySQL 8.0+ 在 RC 下不产生幻读问题 - 按“两阶段锁协议”重排事务内语句顺序：把冲突概率最高的更新（如热点账户余额）放在最后执行，缩短其持锁时间
- 检查
innodb_lock_wait_timeout值（默认 50 秒），线上建议设为 10–30 秒，避免一个慢事务拖垮整个连接池
真正容易被忽略的是：锁等待问题往往藏在“看起来没问题”的 SQL 里——比如一个没走索引的 FOR UPDATE，或一个在事务开头就锁定宽泛范围的查询。排查时别只盯 SHOW ENGINE INNODB STATUS 里的死锁日志，先确认每条加锁语句是否真的只锁了该锁的那几行。
