MySQL 5.5 默认切换为InnoDB，根本原因是MyISAM在高并发写入和崩溃恢复上无法满足真实业务需求：表级锁导致写入阻塞，无事务机制使断电后数据处于不一致状态，而InnoDB通过行级锁、redo log与undo log实现了秒级崩溃恢复和ACID保障。
MySQL 5.5 默认切 InnoDB 是因为 MyISAM 在并发写和崩溃恢复上彻底扛不住了
不是 InnoDB 突然变强了，而是 MyISAM 在真实业务场景里频繁暴雷：一次 UPDATE 卡住整张表、服务器断电后 repair table 跑半小时、订单生成一半库存扣了但订单没写入——这种状态既不可回滚也不可重放。InnoDB 的 redo log + undo log 组合，让“写入中途断电”从数据灾难变成日志重放的常规流程。
行级锁 vs 表级锁：高并发下锁等待从“全表排队”变成“只锁那几行”
MyISAM 的 LOCK TABLES 是粗粒度的，哪怕你只改 WHERE id = 123，其他所有 INSERT/UPDATE 都得等；InnoDB 基于索引实现行锁，只要不冲突，100 个连接可以同时更新不同主键的记录。但注意：没走索引的 WHERE 条件（比如 WHERE status = 'pending' 且 status 没索引），InnoDB 会退化为间隙锁甚至全表扫描加锁，实际效果可能比 MyISAM 还卡。
崩溃恢复能力不是“有就行”，而是“秒级可用”和“人工救库”的区别
MyISAM 崩溃后必须执行 myisamchk 或 REPAIR TABLE，表越大耗时越长，期间完全不可读写；InnoDB 启动时自动做 crash recovery：用 redo log 重放未刷盘的事务，用 undo log 回滚未提交的修改——整个过程在秒级完成，应用无感。这个能力直接决定了它能不能进金融、电商这类核心系统。
默认引擎切换不是功能叠加，而是 MySQL 架构重心转向事务语义优先
MySQL 5.5 把 InnoDB 设为默认，背后是 Server 层对存储引擎 API 的深度适配：比如 XA 分布式事务支持、information_schema 中 InnoDB 专用视图（INNODB_TRX, INNODB_LOCK_WAITS）、以及后续 5.6/5.7 中在线 DDL 对 InnoDB 的原生支持。一旦默认设为 InnoDB，整个生态（ORM、监控工具、备份方案）就围绕它的事务模型构建——反过来，再想退回 MyISAM 就等于放弃整个现代数据库协作链路。
真正容易被忽略的是：InnoDB 的可靠性优势不是靠“多加几个配置”堆出来的，而是从页结构（16KB page）、区（extent）、段（segment）到 Buffer Pool 的整套设计咬合在一起的结果。换引擎不是改个 ENGINE=InnoDB 就完事，它要求你理解事务怎么落盘、锁怎么申请、MVCC 版本怎么组织——否则照样写出死锁频发、SELECT 扫全表、INSERT 变慢的代码。
