MySQL 5.5起InnoDB为默认存储引擎，因其全面支持ACID、崩溃恢复、MVCC、行锁和外键等事务安全特性；验证方式为SHOW ENGINES或SHOW CREATE TABLE；关键参数包括innodb_buffer_pool_size、innodb_flush_log_at_trx_commit、innodb_file_per_table和innodb_log_file_size。
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 不仅是默认，更是唯一合理选择——它的“默认”背后，是多年生产环境锤炼出的稳定性与一致性权衡。
