必须用InnoDB：MyISAM不支持事务，无崩溃恢复、仅表级锁、COUNT(*)语义错误、无外键；InnoDB通过redo/undo log保障ACID、行级锁、事务一致性COUNT、自动崩溃恢复及外键约束。
必须用 InnoDB：只要业务里存在“写后需回滚”“多步操作要一起成功或一起失败”的逻辑，比如支付扣款+库存更新+订单生成，MyISAM 就不满足底线要求。
事务支持：没有 START TRANSACTION 就别选 MyISAM
MyISAM 对所有 INSERT/UPDATE/DELETE 都立即落盘，不支持原子性。哪怕你写了 BEGIN; INSERT; UPDATE; COMMIT;，MySQL 也只会当作三条独立语句执行——中间崩溃，数据就残缺了。
InnoDB 通过 redo log 和 undo log 实现真正的 ACID：崩溃后重启自动恢复到最近一次 COMMIT 状态；回滚时能精确撤销未提交的变更。
- 常见错误现象：
MyISAM订单表中用户已支付，但库存没扣减，且无法修复 - 实操建议：资金、权限、库存、日志状态变更类表，一律强制指定
ENGINE=InnoDB - 容易踩的坑：
MyISAM的AUTO_INCREMENT不受事务保护——回滚后自增 ID 仍会递进；InnoDB在 MySQL 8.0+ 中行为有优化，但测试环境仍需验证实际表现
高并发写场景下，MyISAM 的表级锁是硬伤
MyISAM 所有写操作（INSERT/UPDATE/DELETE）都会对整张表加排他锁，后续任何读写都排队等待。哪怕只是更新一行，其他线程查另一行也得等。
InnoDB 默认行级锁，UPDATE users SET status=1 WHERE id=123 只锁住这一行，其余记录照常可读可写。
- 常见错误现象：后台批量导入时，前台用户列表查询长时间卡住，监控显示大量
Waiting for table metadata lock - 实操建议：任何带用户交互的系统（CMS 后台、电商管理端），哪怕写入量不大，也应默认用
InnoDB - 容易踩的坑：
InnoDB的行锁只在 WHERE 条件命中索引时生效；若WHERE name LIKE "%abc%"无法走索引，也会退化为全表扫描+意向锁（效果接近表锁）——这不是引擎缺陷，而是查询设计问题
COUNT(*) 性能差异本质是语义不同，不是快慢问题
MyISAM 快，是因为它把精确行数缓存在内存里，SELECT COUNT(*) FROM t 直接返回变量值；但这个值在事务隔离下不准确——比如你刚 INSERT 一条但没 COMMIT，别人查不到，而 MyISAM 的缓存值已经变了。
InnoDB 每次都按当前事务可见性去扫索引（通常是主键），结果严格符合隔离级别定义，但代价是可能变慢。
- 使用场景：报表统计、归档脚本这类对实时性要求低、且能接受近似值的场景，
MyISAM的COUNT(*)有参考价值；在线接口中依赖COUNT(*)做分页或状态判断，必须用InnoDB并搭配覆盖索引或缓存层 - 参数差异：
innodb_file_per_table=ON（默认）让每张表生成独立.ibd文件，空间可回收；关掉则所有表挤在ibdata1里，删表后空间永远不释放
真正难决策的点往往不在引擎本身，而在历史包袱：比如老系统用 MyISAM 建了全文索引，而 InnoDB 在 MySQL 5.6+ 虽已支持 FULLTEXT，但语法细节和分词逻辑仍有差异。这种时候，不要试图“一刀切换引擎”，先确认 ALTER TABLE ... ENGINE=InnoDB 后全文查询是否还返回预期结果。
