myisam仅支持表锁，不支持行锁或页锁；所有读写操作均锁定整张表，导致高并发下严重阻塞，且无事务机制，锁生命周期由单条语句决定，根本解决需迁移到innodb。
MyISAM默认只支持表级锁，没有行级锁能力
MyISAM引擎在设计上就**不支持行锁或页锁**，所有读写操作都必须对整张表加锁。这意味着哪怕你只更新 WHERE id = 123 这一行，它也会锁住整个表，其他任何对这张表的写操作（INSERT/UPDATE/DELETE）都会被阻塞，连并发读也会被后续写操作拖住。
对比 InnoDB：即使没走索引，InnoDB 也优先尝试行锁；只有在极端情况（如全表扫描 + 无索引）下才可能升级为表锁。而 MyISAM 没有“升级”一说——它从一开始就是表锁。
读写操作天然串行，高并发下极易堆积等待
MyISAM 的读锁（READ LOCK）允许多个读并发，但一旦有写请求进来，就得等所有读完成；而写锁（WRITE LOCK）是独占的，会把后续所有读、写全部挂起。这种串行模型在以下场景会快速暴露问题：
- 一个慢查询（比如
SELECT ... FROM myisam_table WHERE unindexed_col = 'x'）执行几十秒，期间所有更新都被卡在Waiting for table level lock - 批量导入用
LOAD DATA INFILE或大量INSERT，持续持有写锁 - 应用未及时关闭连接，导致
SHOW PROCESSLIST中残留大量 Sleep 状态但锁未释放
此时 Table_locks_waited 状态值会明显上升，是诊断的第一信号。
DDL 操作会强制获取写锁，且不可中断
对 MyISAM 表执行 ALTER TABLE、REPAIR TABLE、OPTIMIZE TABLE 时，MySQL 必须先获得排他写锁。这类操作往往耗时较长，且无法被 KILL 中断（REPAIR 尤其危险）。如果此时表上有活跃查询或更新，整个表就彻底不可用。
更麻烦的是：MyISAM 索引损坏后必须 REPAIR，而该操作本身又会引发长时间锁表——形成恶性循环。
没有事务机制，锁生命周期完全依赖语句执行时间
MyISAM 不支持事务，所以没有 BEGIN/COMMIT 控制锁范围。锁的获取和释放完全绑定在单条语句上：
-
SELECT→ 加读锁 → 语句结束立即释放 -
UPDATE→ 加写锁 → 语句结束立即释放
看似简单，实则脆弱：一条慢 SELECT 就能堵死写入；而开发者容易误以为“只是查一下”，忽略其对写操作的实际阻塞影响。这种不可控的锁生命周期，在复杂业务逻辑中很难预估和协调。
真正棘手的地方在于：MyISAM 的表锁争用不是配置能调优出来的，它是引擎层面的硬限制。只要还在用 MyISAM，就绕不开“一写全堵”这个本质约束——迁移至 InnoDB 是唯一根治方式，其他所谓优化（比如加索引、拆表）只能缓解，无法消除锁粒度问题。
