innodb是必须选择，因其具备acid事务、崩溃自动恢复、行级锁（索引命中时）、聚簇索引、外键约束等能力；myisam缺乏日志机制、仅表级锁、无事务支持、易数据损坏，仅适用于极少数只读静态场景。
默认用 InnoDB，除非你明确知道为什么还要选 MyISAM。 这不是偏好问题，而是数据安全、并发能力和运维成本的硬性门槛。
事务支持与崩溃恢复：ACID 不是可选项
业务涉及资金、订单、库存扣减等任何需要“全成功或全失败”的场景，InnoDB 是唯一合理选择。它靠 redo log 和 undo log 实现原子性与崩溃后自动恢复——数据库重启就能回正，无需人工干预。MyISAM 没有日志机制，断电或异常终止后极易出现 .MYD 文件损坏，必须手动运行 REPAIR TABLE，且修复结果不可预测。
-
InnoDB的COMMIT/ROLLBACK是底层能力，应用层不用额外封装也能保证一致性 -
MyISAM所有写操作都是“直写磁盘”，没回滚概念，UPDATE中途失败，部分行已改，部分未改，状态不一致 - 即使只是临时表，若需在事务中使用（比如存储过程中间结果），
MyISAM表无法参与事务，会破坏整体一致性
锁粒度与并发写：行锁 ≠ 自动生效
InnoDB 的行级锁只在查询条件命中索引时才真正生效；否则退化为表锁，效果和 MyISAM 无异。而 MyISAM 的表级锁是刚性的：一个 UPDATE 就堵死整张表的读写。
-
WHERE id = ?（id是主键）→ 真正锁单行 -
WHERE status = 'pending'（status无索引）→ 锁全表，高并发下性能崩塌 -
MyISAM所谓“并发插入”仅指INSERT在表尾追加且无其他读写时才允许，不是真正的并发写 - 写多读少场景下，
MyISAM的锁争用会直接拖垮吞吐量，监控里能看到大量Waiting for table level lock
索引结构与主键约束：聚簇索引决定物理布局
InnoDB 必须有主键，数据按主键顺序物理存储在 .ibd 文件中；MyISAM 数据和索引完全分离，存于 .MYD 和 .MYI 文件，主键非必需。
-
InnoDB主键即聚簇依据，二级索引叶子节点存的是主键值，非主键查询可能触发回表 -
MyISAM二级索引叶子节点存的是.MYD中的物理偏移，查询不依赖主键，但无法避免随机 IO -
InnoDB的AUTO_INCREMENT字段必须是索引的第一列；MyISAM允许在联合索引中非首列递增，但实际极少用到 - 没有显式主键时，
InnoDB会隐式生成ROW_ID，但该值不对外暴露，也无法用于业务逻辑
外键与运维现实：功能缺失会推高开发和维护成本
InnoDB 支持外键，能在数据库层强制参照完整性；MyISAM 把这事全甩给应用层，错一次就埋个数据脏点。
- 删除用户前，
InnoDB可设ON DELETE CASCADE自动清理关联订单；MyISAM得靠应用先查再删，漏一步就留孤儿记录 -
MyISAM的COUNT(*)快是因为自带行数计数器，但该值在事务未提交时不准，且无法反映 MVCC 下的可见行数 - 备份
MyISAM表可直接拷贝.frm+.MYD+.MYI，但跨版本或跨平台易出兼容问题；InnoDB推荐用mysqldump或mysqlpump，虽然慢，但语义可靠 -
MyISAM的全文索引已被 Elasticsearch/Solr 替代多年，MySQL 8.0+ 的InnoDB全文索引已足够实用，无需妥协
真正需要考虑 MyISAM 的场景只剩极少数：静态报表表、只读归档表、或 legacy 系统中无法重构的模块。只要表有写入、有关联、有事务需求，InnoDB 就不是“更好”，而是“必须”。容易被忽略的是：哪怕只有一张表用 MyISAM，它也会成为整个库的可靠性短板——因为故障恢复、备份策略、监控指标都得为它单独适配。
