innodb是默认且必须优先选择的存储引擎，myisam仅适用于极少数只读静态场景；因其具备acid事务、崩溃自动恢复、行级锁（索引命中时）、聚簇索引、外键约束等能力，而myisam缺乏日志机制、仅表级锁、无事务支持、易数据损坏。
InnoDB 是默认且应优先选择的存储引擎，MyISAM 仅在极少数只读、静态、无一致性要求的场景下才可考虑——这不是性能偏好问题，而是数据安全与运维成本的硬门槛。
事务支持：ACID 不是可选项，而是底线
涉及资金、订单、库存变更等任何“全成功或全失败”逻辑，必须用 InnoDB。它靠 redo log 和 undo log 实现原子性与崩溃后自动恢复；MySQL 重启就能回正，无需人工干预。MyISAM 没有日志机制，断电或异常终止后 .MYD 文件极易损坏，只能手动执行 REPAIR TABLE，修复结果不可控。
InnoDB 的 COMMIT/ROLLBACK 是底层能力，应用层不用额外封装也能保证一致性；MyISAM 所有写操作都是直写磁盘，UPDATE 中途失败，部分行已改、部分未改，状态必然不一致。
即使只是临时表，若需在存储过程中参与事务（如中间计算结果），MyISAM 表无法加入事务，会破坏整体一致性。
锁粒度：行锁 ≠ 自动生效，索引是关键
InnoDB 的行级锁只在 WHERE 条件命中索引时才真正起效；否则退化为表锁，效果和 MyISAM 一样差：
-
WHERE id = ?（id是主键）→ 真正锁单行 -
WHERE status = 'pending'（status无索引）→ 锁全表，高并发下Waiting for table level lock大量堆积
MyISAM 的表级锁是刚性的：一个 UPDATE 就堵死整张表的读写。“并发插入”仅指 INSERT 在表尾追加且无其他读写时才允许，并非真正并发写。写多读少场景下，MyISAM 锁争用会直接拖垮吞吐量。
索引与主键：聚簇索引决定物理布局
InnoDB 必须有主键，数据按主键顺序物理存储在 .ibd 文件中；没有显式主键时，会隐式生成 6 字节 ROW_ID（不对外暴露，不可用于业务逻辑）。
InnoDB 的二级索引叶子节点存的是主键值，非主键查询可能触发回表；MyISAM 数据和索引完全分离（.MYD + .MYI），二级索引叶子节点存的是物理偏移，查询不依赖主键，但无法避免随机 IO。
InnoDB 的 AUTO_INCREMENT 字段必须是索引的第一列；MyISAM 允许在联合索引中非首列递增，但实际极少用到。
外键与运维现实：功能缺失会推高开发成本
InnoDB 支持外键，能在数据库层强制参照完整性；MyISAM 把这事全甩给应用层，错一次就埋个数据脏点。
例如删除用户前，InnoDB 可设 ON DELETE CASCADE 自动清理关联订单；MyISAM 得靠应用先查再删，漏一步就留下孤儿记录。
全文索引方面：MyISAM 原生支持；InnoDB 自 MySQL 5.6 起已支持，8.0 后更成熟——不必为这点功能妥协其他核心能力。
InnoDB 就天然高并发，结果上线后发现写操作卡顿严重，一查发现全是 WHERE 条件没走索引，锁了整张表。
