MyISAM表一写就锁全表，因其仅支持表级锁，任何INSERT、UPDATE、DELETE均对整表加独占写锁，阻塞所有其他读写请求；CONCURRENT INSERT仅在无空洞且无WHERE时有限生效，本质是设计限制而非配置或SQL问题。
MyISAM 表一写就锁全表，不是配置没调好，也不是 SQL 写得差，是它根本就没设计“读写并发”这个能力——写操作必然触发表级写锁，所有其他读、写请求全部排队等。
MyISAM 的写锁为什么阻塞所有读操作
MyISAM 只支持表级锁，没有行锁或页锁概念。当执行 INSERT、UPDATE 或 DELETE 时，MySQL 会立即对整张表加独占写锁（table write lock），此时：
- 其他会话的任何
SELECT都会被挂起，直到写锁释放 - 其他会话的任何写操作（包括另一个
INSERT）也必须等待 - 即使只更新一行，锁的粒度仍是整张表；不存在“我改我的，你查你的”这种隔离
-
CONCURRENT INSERT是唯一例外，但仅在满足两个苛刻条件时生效：表尾无空洞（未发生过DELETE）、且INSERT不带WHERE条件
如何确认当前正被 MyISAM 表锁卡住
别猜，直接查状态。以下命令能快速暴露问题：
- 运行
SHOW PROCESSLIST，看是否有大量线程状态为Locked或Waiting for table level lock - 查慢查询日志，若频繁出现
Waiting for table level lock，基本可断定是 MyISAM 表锁瓶颈 -
SHOW OPEN TABLES WHERE In_use > 0能列出当前被锁定的表及其使用次数 - 注意：
information_schema.INNODB_TRX对 MyISAM 无效，别白查
ALTER TABLE ENGINE=InnoDB 前必须检查的四件事
直接跑 ALTER TABLE t ENGINE=InnoDB 很容易失败或埋坑，尤其在线上环境：
- 磁盘空间是否够？转换过程会先建新 InnoDB 表再拷数据，临时空间至少等于原表大小
- 主键是否存在？InnoDB 强依赖聚簇索引；若原表无主键，MySQL 会自动生成隐藏
ROW_ID，导致二级索引膨胀、范围查询变慢 - 全文索引是否用了？MyISAM 支持 FULLTEXT，但 MySQL 5.6 及更早版本的 InnoDB 不支持；5.7+ 才完整兼容
- 外键是否定义了？MyISAM 根本不支持外键，转 InnoDB 后需补全约束，否则迁移后可能丢失业务一致性保障
大表转换时避免锁死业务的实操选择
小表（比如 ALTER，但务必避开高峰；大表千万不能直接改：
-
pt-online-schema-change是最稳妥的选择：它通过影子表+触发器同步数据，全程不锁原表，但要求从库延迟低、触发器未被禁用 -
gh-ost更轻量，不依赖触发器，适合高负载或禁用触发器的环境，但需要额外部署和监控 - 手动双写+切换方案风险高，容易漏数据，除非有强定制需求，否则不推荐
- 切记：无论用哪种工具，都要提前在从库验证转换结果、检查主从延迟、确认备份可用
真正难的不是执行 ALTER，而是确认那张表有没有隐式依赖——比如某个报表脚本靠 CONCURRENT INSERT 维持低延迟，转 InnoDB 后行为就变了；或者某个归档逻辑假定了 MyISAM 的非事务性，这些细节往往比锁本身更致命。
