myisam在mysql 5.7高并发下必须弃用，因其表级锁导致全表阻塞、无事务与崩溃恢复机制致数据逻辑不一致、且不支持json/gis/外键等5.7核心企业功能。
MyISAM 在 MySQL 5.7 高并发场景下必须弃用，核心原因不是性能差，而是它根本无法保证数据逻辑一致——一次中断、一个断电、一条没执行完的 ALTER，都可能让表“看起来正常，查出来却错得离谱”，且数据库自己完全不报错。
表级锁在高并发下直接卡死业务
MyISAM 对任何写操作（INSERT/UPDATE/DELETE/REPLACE）都加整张表的锁，读请求也得排队等锁释放：
- 只要有一条 UPDATE 在跑，所有其他读写全部阻塞，
SHOW PROCESSLIST中大量出现Waiting for table level lock - 用户中心、订单、库存类高频更新表，一压就堵；而 InnoDB 默认行级锁，张三改第 5 行、李四改第 200 行互不影响
- 注意：InnoDB 若
WHERE条件未走索引（如status = 1但status列无索引），也会升级为表锁——这不是引擎缺陷，是用法问题
崩溃后无法自检或恢复，数据错位静默发生
MyISAM 没有 UNDO LOG，也没有 REDO LOG，所有变更直接刷到 .MYD（数据）和 .MYI（索引）文件：
- 断电或进程被杀时，
.MYD和.MYI可能不同步，SELECT COUNT(*)和SELECT * FROM t WHERE id > 1000返回矛盾结果 -
REPAIR TABLE只是暴力重建索引，不验证业务逻辑是否一致（比如金额字段是否与订单状态匹配） - 主从复制中，从库执行完
REPLACE INTO后看似成功，但关键字段已错位，且无任何错误日志可查
GIS、JSON、外键等企业级功能全依赖 InnoDB
MySQL 5.7 引入的很多关键能力，在设计层面就与 MyISAM 不兼容：
- GIS 空间索引（
SPATIAL）虽文档说 MyISAM 支持，但 5.7 实际中优化器常不识别，EXPLAIN显示type: ALL；而 InnoDB 的 R-tree 索引可被ST_Intersects()等函数真正触发 -
JSON类型、多源复制、Performance Schema深度监控等功能，全部需要事务上下文和行级并发控制，MyISAM 根本无法承载 - InnoDB 外键约束在 5.7 已真正可用——不是语法支持，而是在高并发更新时能保证参照完整性不被绕过
禁用 MyISAM 并不等于删除，但绕过限制太容易
即使你配置了 disabled_storage_engines="MyISAM"，仍有多个隐式路径会悄悄创建 MyISAM 表：
-
CREATE TABLE t AS SELECT * FROM myisam_table会沿用源表引擎，不校验白名单 - 从旧
mysqldump导入的 SQL 若含ENGINE=MyISAM，服务端照样执行（尤其老备份还原到新环境时） - 已有 MyISAM 表仍可读写，直到你主动转换；但它们会拖慢
information_schema查询、干扰系统统计、在 8.0 升级后引发启动失败
真正难处理的，是那些没报错、只是结果异常的场景：比如某个存储过程里 CREATE TEMPORARY TABLE 没指定 ENGINE，旧环境默认 MyISAM，新环境默认 InnoDB，因事务行为差异导致中间状态不一致——这种必须结合业务逻辑回归验证，不能只靠建表语句检查。
