MySQL 5.5 起，
InnoDB就是默认存储引擎——不是“推荐”，而是“开箱即用”。只要你没在配置里显式改掉，所有
CREATE TABLE建的表，底层都是 InnoDB。
为什么 MySQL 默认选 InnoDB 而不是 MyISAM？
核心就一条：事务安全不可妥协。MyISAM 不支持事务、不支持行锁、崩溃后需手动
REPAIR TABLE，而 InnoDB 把 ACID、崩溃自动恢复、MVCC 并发读写全包圆了。 事务失败？靠
undo log回滚到一致状态 服务器突然断电？重启后自动重放
redo log恢复未刷盘的修改 多人同时查/改同一张表？靠行锁 + MVCC 实现读不阻塞写、写不阻塞读 删主表数据，从表关联记录也要跟着删？
FOREIGN KEY级联约束直接生效
这些不是“加分项”，是现代 OLTP 场景的底线要求——InnoDB 是唯一满足全部底线的内置引擎。
怎么确认当前 MySQL 正在用 InnoDB？
别只看文档说“默认”，要亲手验证。两个最稳的方式：
查全局支持情况：SHOW ENGINES;找
InnoDB行，
SUPPORT列显示
DEFAULT或
YES即可 查具体表实际用的引擎：
SHOW CREATE TABLE users;输出里明确带
ENGINE=InnoDB
⚠️ 注意：即使配置了
default-storage-engine=InnoDB，如果建表时写了
ENGINE=MyISAM，那这张表就真用 MyISAM——引擎选择以建表语句为准，配置只是兜底。
哪些关键参数直接影响 InnoDB 行为？
不用调满屏参数，盯住这四个，就能避开 90% 的性能或一致性问题：
innodb_buffer_pool_size：缓冲池大小，建议设为物理内存的 50%–70%。太小 → 频繁磁盘 IO；太大 → 挤占系统其他进程内存
innodb_flush_log_at_trx_commit：控制日志刷盘时机。值为
1（默认）最安全，每次事务提交都刷盘；设为
0或
2可提速，但断电可能丢最近 1 秒事务
innodb_file_per_table：必须设为
ON（5.6.6+ 默认开启）。否则所有表数据都挤进系统表空间
ibdata1，删表后空间根本无法回收
innodb_log_file_size：重做日志单个文件大小。增大能减少 checkpoint 频率、提升写入吞吐，但修改前必须停库、删旧
ib_logfile*文件，否则启动失败
改这些参数后，一定要重启 MySQL 生效，且
innodb_log_file_size这类涉及磁盘文件结构的，操作前务必备份。
什么时候不该用 InnoDB？
它强大，但不是万能胶。真遇到这些场景，得重新评估：
纯静态报表表（比如历史归档日志），只读、无关联、数据量极大 → MyISAM 的压缩和全文索引可能更省空间 超低配嵌入式设备（内存 需要全文索引且用的是 MySQL 5.6 以前版本（InnoDB 全文索引 5.6 才支持）但绝大多数 Web 应用、电商、金融类业务，InnoDB 不仅是默认，更是唯一合理选择——它的“默认”背后，是多年生产环境锤炼出的稳定性与一致性权衡。
