优先选InnoDB：支持事务、外键、高并发写入，行级锁+MVCC避免锁表；MyISAM仅适用于纯读、静态统计场景，且无崩溃恢复能力，复制中易致从库延迟。
怎么一眼看出该用 InnoDB 还是 MyISAM？
看表有没有事务、外键、高并发写入需求——有，就选 InnoDB；纯读、只做统计、数据量大且不更新，才考虑 MyISAM。MySQL 5.5 起默认就是 InnoDB，不是历史惯性，是它真能扛住业务压力。
-
InnoDB的行级锁 + MVCC 让 100 个用户同时改订单状态不会互相卡死；MyISAM一写就锁整张表，其他查询全排队 - 如果你建表时没指定
ENGINE=，现在查SHOW CREATE TABLE user;，八成看到的是ENGINE=InnoDB - 别因为“听说 MyISAM 读得快”就换引擎——混合读写下它的性能反而是拖累，
MyISAM的 0.9 秒纯读优势，在并发写入后瞬间变成 6.5 秒的混合操作延迟
为什么 MyISAM 的 .MYD/.MYI 文件不能直接拷贝到 InnoDB 表？
结构根本不同：MyISAM 是索引和数据物理分离（.MYI 存 B 树索引，.MYD 存行记录）；InnoDB 是聚簇索引，主键值直接决定数据在磁盘上的物理位置，数据即索引。
- 直接复制文件会导致
InnoDB启动失败，报错类似Tablespace is missing for table `db`.`t1` - 想迁移，必须用逻辑导出：先
mysqldump --no-create-info --skip-triggers db t1 > t1_data.sql，再建新InnoDB表，最后导入 -
ALTER TABLE t1 ENGINE=InnoDB;看似简单，但大表会锁死整个表、占满临时空间，线上慎用
哪些配置项会悄悄让 MyISAM 变脆弱？
MyISAM 没有崩溃恢复能力，靠操作系统刷盘和人为维护。几个关键参数不调好，表损坏就是分分钟的事。
-
myisam_recover_options默认是空的，意味着崩溃后 MySQL 不自动检查修复——建议设为FORCE,BACKUP -
key_buffer_size太小会导致索引缓存不足，频繁 IO；太大又挤占其他引擎内存，一般设为物理内存的 25% 就够 - 不要依赖
OPTIMIZE TABLE来“保养”MyISAM——它本质是重建表，期间不可读写；而InnoDB的OPTIMIZE TABLE实际是ALTER TABLE ... FORCE，影响小得多
全文索引不是 MyISAM 的专属了
MySQL 5.6 开始，InnoDB 原生支持 FULLTEXT 索引，语法完全一致。现在还为了全文搜索硬上 MyISAM，等于主动放弃事务和并发能力。
- 建索引写法一样：
ALTER TABLE articles ADD FULLTEXT(title, content);—— 引擎不同，语句不用改 -
InnoDB全文索引支持停用词、布尔模式、自然语言模式，和MyISAM功能对齐，只是早期版本分词精度略低（5.7+ 已无差别） - 如果业务既要搜又要改订单状态，别拆成两个引擎——用
InnoDB+FULLTEXT，省去双写、同步、一致性校验的麻烦
真正容易被忽略的，是 MyISAM 表在主从复制中遇到 INSERT ... SELECT 或批量 UPDATE 时，可能因锁表导致从库延迟飙升——这问题不会报错，只会默默拖慢你的监控曲线。
