MyISAM表锁是并发瓶颈的根源，必须迁至InnoDB；其表级锁设计决定无法通过调参、索引或SQL优化解决，迁移需严控事务行为、索引覆盖与锁序规范。
直接结论：MyISAM 表锁是并发瓶颈的根源，不能靠调参或索引优化解决，必须迁移到 InnoDB。 迁移本身不难，但若忽略引擎行为差异（比如事务、锁机制、自动提交），上线后反而会引发更隐蔽的阻塞或数据不一致问题。
为什么 MyISAM 的表锁无法“优化”只能替换
MyISAM 的 LOCK TABLES ... WRITE 是全表排他锁，任何写操作都会阻塞其他所有读写请求。即使只更新一行，整个表不可用——这不是锁粒度细不细的问题，而是设计上就不支持行级并发控制。你无法通过加索引、改 SQL 或调 innodb_lock_wait_timeout 让它支持行锁，因为它的存储引擎压根没实现这个能力。
常见误判场景包括：
- 看到慢查询日志里有
Waiting for table level lock，以为是某条 SQL 写法差，实则是引擎限制 - 在 MyISAM 表上加了主键和唯一索引，仍无法避免锁表——索引对 MyISAM 的锁机制无影响
- 用
SELECT ... LOCK IN SHARE MODE或FOR UPDATE，MySQL 会直接报错，因为 MyISAM 不支持这些语法
迁移前必须验证的三件事
不是执行 ALTER TABLE t ENGINE=InnoDB 就算完事。InnoDB 和 MyISAM 在语义上有关键差异，漏掉任一环节都可能引发线上故障：
-
autocommit默认开启，但业务代码若依赖 MyISAM 的“自动立即生效”，而没显式COMMIT，切换后会出现事务未提交、数据查不到的情况 - MyISAM 支持全文索引（
FULLTEXT），但 InnoDB 的全文索引行为不同（如停用词、分词逻辑），需重新测试搜索结果 - MyISAM 允许
INSERT和SELECT并发读写（因为读不加锁），而 InnoDB 在默认REPEATABLE READ隔离级别下，普通SELECT走 MVCC 快照读，但UPDATE/DELETE会加 X 锁；若业务有“先查再更”的逻辑且没加FOR UPDATE，可能产生幻读或丢失更新
迁移时最容易被忽略的锁行为陷阱
InnoDB 行锁依赖索引。如果迁移后仍沿用 MyISAM 时代的无索引查询习惯，UPDATE 或 DELETE 会退化为锁全表（准确说是锁所有聚簇索引页），并发性能不升反降：
- 没有
WHERE条件的UPDATE t SET status=1→ 锁全表（InnoDB 也会） -
WHERE字段未建索引（如WHERE phone='138...'但phone无索引）→ 走全表扫描，每行加 X 锁，等效于表锁 - 使用
LIKE '%abc'导致索引失效 → 同样触发全表加锁
务必用 EXPLAIN 检查所有 DML 语句是否命中索引，尤其是迁移后新增的写逻辑。
上线后必须监控的两个指标
迁移完成不等于高枕无忧。InnoDB 的锁竞争比 MyISAM 更“安静”，但后果更严重：
- 关注
SHOW ENGINE INNODB STATUS输出中的TRANSACTIONS部分，重点看是否有长时间未提交事务（Trx has been waiting或lock struct(s)数量突增） - 监控
Innodb_row_lock_waits和Innodb_row_lock_time_avg，若平均等待时间超过 10ms 或每秒等待次数 >5，说明存在热点行冲突，需按“拆分状态暂存+异步聚合”思路重构，而不是回退到 MyISAM
真正卡住系统的，从来不是锁本身，而是事务持有锁的时间。InnoDB 给了你行锁的能力，但怎么用，取决于你是否把“短事务”“确定性锁序”“索引驱动更新”变成开发规范的一部分。
