金融行业明令禁止使用MyISAM，因其不支持事务、无redo/undo日志、仅表级锁、无崩溃恢复能力，与金融系统对数据一致性、原子性及高可用的硬性要求直接冲突。
金融行业在MySQL规范中明令禁止使用MyISAM，不是出于性能偏好或风格选择，而是因为它的核心机制与金融系统对数据一致性、崩溃可恢复性、事务原子性的硬性要求直接冲突——只要存在一个MyISAM表，就可能在主从切换、实例重启、权限变更或备份恢复时引发资金错位、状态丢失、服务不可用等生产事故。
MySQL 8.0+ 启动失败：系统表引擎不一致直接拒启
MySQL 8.0.33 起，启动阶段会对mysql库所有系统表（如mysql.user、mysql.db）做引擎强制校验。若其中任一表仍是MyISAM，服务立即退出，报错：
ER_UNKNOWN_STORAGE_ENGINE: Unknown storage engine 'MyISAM'
这不是配置能绕过的：
-
disabled_storage_engines=MyISAM只拦截新建表，不修复已有表 -
skip-myisam在系统表加载完成后才生效，此时校验早已失败 -
mysqldump还原旧备份时若未清除ENGINE=MyISAM，会自动重建MyISAM系统表 -
mysql_upgrade自 8.0.16 起已弃用，不再转换任何系统表
崩溃后数据逻辑错乱：无日志、不自检、静默损坏
MyISAM没有redo log和undo log，所有写操作直写.MYD（数据）和.MYI（索引）文件。断电、OOM 或 kill -9 后，两文件极易偏移，典型现象包括：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
SELECT COUNT(*)和SELECT * FROM t WHERE id > 1000返回矛盾结果 - 主从复制中，
REPLACE INTO在从库看似成功，但金额字段已错位，且SHOW SLAVE STATUS无任何错误提示 -
CHECK TABLE常报error: 134 (record header crashed)，而REPAIR TABLE只是暴力重建索引，不验证业务一致性 - 云数据库平台无法自动恢复，必须人工介入
myisamchk，期间服务中断、SLA失效
事务与并发模型完全不满足金融场景
金融核心链路依赖事务的原子性、隔离性和可重复读能力，MyISAM在这三方面全部缺失：
-
INSERT ... ON DUPLICATE KEY UPDATE实际执行为“先删后插”，自增ID跳变，且删除与插入无法原子化 -
SELECT ... FOR UPDATE在MyISAM中被静默忽略，应用层以为加了锁，实际并发写入仍在发生 - 任何
INSERT/UPDATE/DELETE都触发整表排他锁，写锁优先级高于读锁，导致读请求长时间饥饿 - 外键约束语法被完全忽略，
FOREIGN KEY形同虚设，跨表状态一致性无法保障
主从复制与高可用链路静默失效
MySQL 8.0 默认binlog_format=ROW，但MyISAM不支持行格式日志，复制自动退化为STATEMENT模式：
-
NOW()、UUID()、USER()等非确定性函数在主从产生不同值，审计类业务逻辑错乱 - InnoDB Cluster、MHA、Orchestrator 等高可用方案依赖事务一致性与崩溃可恢复性，
MyISAM表存在即意味着故障转移失败概率趋近100% - 云数据库的读写分离代理（如 RDS Proxy）靠
TRX_STATE判断事务上下文；MyISAM查询一律视为非事务型，强制路由到主库，拖垮核心链路 -
mysqldump --single-transaction对MyISAM无效，备份必须加--lock-tables，整库阻塞数分钟
真正麻烦的不是语法替换，而是老代码里那些隐含假设：“MyISAM写得快所以不用管事务”“COUNT(*)快所以能当实时统计用”“表锁简单所以能当简易同步手段”——这些逻辑在InnoDB下会暴露为死锁、幻读、重复记录或性能毛刺，必须逐条重审，不能只改ENGINE=InnoDB。
