InnoDB能替代MyISAM而反之不行，因其支持事务、行级锁、外键和崩溃恢复，MyISAM四项全无；高并发写、数据一致性场景下MyISAM直接失效，且官方自5.5起已将其弃用为默认引擎。
为什么InnoDB能替代MyISAM，但反过来不行
因为InnoDB支持事务、行级锁、外键和崩溃恢复，而MyISAM这四项全不支持——这不是“功能多一点”的问题，是底层能力代差。一旦业务涉及并发写、数据一致性要求（比如订单状态变更、库存扣减），MyISAM就会直接失效。
-
INSERT或UPDATE时，MyISAM会锁整张表，其他读写全部排队；InnoDB只锁被改的行，其余行照常访问 - MySQL 5.5+ 默认引擎就是
InnoDB，官方早已放弃对MyISAM的增强投入 - MyISAM 的
.MYD/.MYI文件结构脆弱，断电或崩溃后容易索引损坏，且无自动修复机制 - 虽然
SELECT COUNT(*)在MyISAM上快（靠内部计数器），但这个优势在加了WHERE条件后立刻归零
哪些场景下MyISAM还“看似能用”，实则危险
有人觉得“我这表只读、不更新，用MyISAM省资源”，但现实里这种静态假设极难成立。哪怕只是加个 ALTER TABLE ... ADD COLUMN，MyISAM也会锁表几分钟，而InnoDB在 ALGORITHM=INPLACE 下可在线执行。
- 地区字典表、行业编码表等“理论上永不变更”的表：一旦需要热更新（比如新增行政区划），MyISAM只能停服重建
- 日志类大表：MyISAM压缩率低，
ROW_FORMAT=COMPRESSED的InnoDB表实际磁盘占用常比MyISAM更小 - 全文检索：MySQL 5.6+ 的
InnoDB已支持FULLTEXT索引，无需为这点功能倒退到MyISAM - 备份恢复：MyISAM不能做热备（
mysqldump --single-transaction对它无效），而InnoDB可配合xtrabackup实现秒级一致性备份
切换引擎不是“改个配置”，而是重建整张表
ALTER TABLE t ENGINE=InnoDB 看似一行命令，背后是拷贝全量数据、重建所有索引、重写聚簇结构的过程。线上表千万级时，操作期间表不可写，且Buffer Pool会被大量刷脏页影响其他查询。
- 务必在低峰期执行，并提前确认磁盘空间是否充足（临时需要约1.5倍原表大小）
- 检查表中是否有
FLOAT或DOUBLE字段——MyISAM允许NULL值存入这些类型，但InnoDB在某些版本会报错，需先ALTER COLUMN ... SET DEFAULT 0 - 如果原表有全文索引，
ALTER后需手动重建：ALTER TABLE t DROP INDEX ft_idx; ALTER TABLE t ADD FULLTEXT(ft_col) - 切完后记得关掉MyISAM相关配置，避免误用：
skip-myisam和disabled_storage_engines=MyISAM
真正该警惕的，是“没意识到自己还在用MyISAM”
很多老系统上线多年，建表语句里没显式指定 ENGINE，但MySQL版本升级后默认已变，结果新表自动用InnoDB，旧表仍卡在MyISAM——造成同一业务里两种引擎混用，连 JOIN 性能都难以预测。
查清现状只要一条SQL：SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db' AND engine = 'MyISAM';。别等主从延迟飙升、死锁报警频发，才翻出十年前的建表脚本。
