MyISAM在高并发写入时必然卡死整张表，因其仅支持表级锁，任一INSERT/UPDATE均加排他锁，阻塞所有读写；迁移到InnoDB并确保索引命中才是根本解法。
MyISAM表级锁在并发写入时直接卡死整张表
只要有一个INSERT或UPDATE执行，MyISAM 就会对整张表加排他锁。其他所有读写请求（包括SELECT）都得排队等它结束。这不是“慢”，是阻塞——SHOW PROCESSLIST里会密集出现Waiting for table level lock，QPS 上不去，但 CPU 和磁盘利用率可能很低。
常见误判：看到“读多写少”就选 MyISAM。实际只要写入频率超过 5–10 次/秒（比如订单创建、日志打点），锁队列就开始堆积。电商场景下一次下单涉及多张表更新，一张 MyISAM 表卡住，整个链路就拖慢。
- MyISAM 的写锁优先级高于读锁，新来的写请求能插队，导致已有读请求长期饥饿
-
ALTER TABLE、CHECK TABLE、REPAIR TABLE全是表级操作，线上执行等于主动停服 - 即使加了
READ LOCAL，也只能缓解部分读写冲突，无法解决写写互斥
InnoDB行级锁不是自动生效的，用错WHERE条件照样锁表
InnoDB 默认行锁，但前提是WHERE条件能命中索引。如果UPDATE t SET status = 1 WHERE user_id = 123中user_id没建索引，InnoDB 会退化为全表扫描+全表加锁，效果和 MyISAM 一样卡。
这不是引擎不行，是用法问题。很多团队压测发现“InnoDB 也锁表”，结果查EXPLAIN发现走了全表扫描。
- 务必对高频
WHERE、JOIN、ORDER BY字段建索引，否则行锁失效 -
SELECT ... FOR UPDATE或UPDATE ... LIMIT N没走索引时，同样会锁全表 - MyISAM 下这种问题不明显，因为它本来就是表锁；InnoDB 下暴露的是真实瓶颈
MyISAM崩溃后无法自恢复，一次断电就可能丢数据
MyISAM 没有redo log和undo log，所有写操作直写.MYD和.MYI文件。断电、OOM 或kill -9 mysqld后，数据与索引可能不同步，CHECK TABLE报error: 126 / 134 / 144是常态。
REPAIR TABLE只是暴力重建索引，不验证业务逻辑是否一致。更危险的是：主从复制中，从库执行完REPLACE INTO看似成功，但金额或状态已错位，且无任何错误日志可查。
- InnoDB 崩溃重启后自动重放
redo log、回滚未提交事务，全程无需人工干预 - MySQL 8.0 已移除所有系统表的 MyISAM 引擎，说明官方早已放弃兜底
- 哪怕你只做日志归档，只要该表会被查询或与其他表关联，就存在一致性风险
disabled_storage_engines="MyISAM"根本封不死存量和绕过路径
配置disabled_storage_engines="MyISAM"只在 MySQL 初始化加载阶段起作用。它拦不住以下情况：
-
CREATE TABLE t AS SELECT * FROM myisam_table—— 新表直接继承源表引擎，不校验白名单 - 用
mysqldump导入含ENGINE=MyISAM的 SQL 文件，服务端照单全收（尤其旧备份还原到新环境） - 已有 MyISAM 表不受影响，仍可读写，直到你主动转换
- MySQL 内部临时表在排序/聚合时仍可能用 MyISAM，不受配置限制
真正要做的不是加个禁用配置，而是用SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.TABLES WHERE ENGINE = 'MyISAM'扫全库，再逐个ALTER TABLE xxx ENGINE=InnoDB。大表记得避开高峰期，用pt-online-schema-change避免锁表。
最常被忽略的一点：混合引擎下事务语义断裂。比如 BEGIN 中同时操作 InnoDB 订单表和 MyISAM 日志表，前半段失败回滚了，后半段日志已落盘不可逆——这不是“性能问题”，是数据一致性灾难。
