MySQL存储引擎是负责将SQL操作转换为磁盘读写的底层组件；InnoDB因行级锁、MVCC、崩溃恢复和外键支持成为事实标准，建表应显式指定ENGINE=InnoDB以防环境差异。
MySQL 存储引擎到底是什么？
它不是“数据库类型”，也不是“配置选项”，而是 MySQL 真正干活的底层组件——负责把你的 INSERT/UPDATE/SELECT 转成磁盘读写操作。你可以理解为：同一个表结构（比如 t_user），用 InnoDB 存，数据和索引一起写进 .ibd 文件；换成 MyISAM，就拆成 .frm+.MYD+.MYI 三个文件，连锁机制、崩溃恢复、事务支持都完全不同。
怎么查当前支持哪些引擎？别只看默认值
执行 SHOW ENGINES \G 是最直接的方式，但要注意输出里 Support 字段的值：
-
DEFAULT：当前 MySQL 实例默认引擎（5.7+ 基本都是InnoDB） -
YES：编译时启用，且运行时可用（比如MEMORY可能被禁用） -
NO：要么没编译进去，要么配置里显式禁用了（如skip-innodb） -
DISABLED：服务启动时加载失败（常见于插件路径错误或依赖缺失）
别只信 SHOW VARIABLES LIKE '%storage_engine%' ——它只告诉你“默认设成啥”，不反映实际可用性。
建表时不指定 ENGINE=？后果很现实
如果你写 CREATE TABLE t_log (id INT) DEFAULT CHARSET=utf8; 却漏了 ENGINE=，MySQL 就按 default_storage_engine 配置走。问题在于：
本书将PHP开发与MySQL应用相结合，分别对PHP和MySQL做了深入浅出的分析，不仅介绍PHP和MySQL的一般概念，而且对PHP和MySQL的Web应用做了较全面的阐述，并包括几个经典且实用的例子。 本书是第4版，经过了全面的更新、重写和扩展，包括PHP5.3最新改进的特性（例如，更好的错误和异常处理），MySQL的存储过程和存储引擎，Ajax技术与Web2.0以及Web应用需要注意的安全
-
开发环境是
InnoDB，测试库却因配置差异用了MyISAM→ 外键失效、事务回滚不生效、高并发更新卡死 - 线上迁移时没检查引擎，
ALTER TABLE t_order ENGINE=InnoDB可能锁表几分钟，尤其大表 -
mysqldump默认不导出 ENGINE 信息，还原后可能变成MyISAM（除非加--force或手动补）
建议：所有建表语句显式声明 ENGINE=InnoDB，哪怕它是默认值——这是防止环境漂移最便宜的保险。
为什么 InnoDB 成了事实标准？关键不在“默认”，而在行为差异
不是因为它功能多，而是它的行为更贴近现代应用的真实约束：
-
InnoDB的行级锁 + MVCC，让UPDATE t_user SET balance=balance-100 WHERE id=123不会阻塞其他用户查id=456的记录；而MyISAM表级锁会让整张表“冻结” -
InnoDB崩溃后靠redo log自动前滚恢复，MyISAM崩溃大概率要REPAIR TABLE，且无法保证数据一致性 -
foreign_key只在InnoDB生效，MyISAM上加外键语法不报错，但纯属摆设
真正容易被忽略的是：即使你只读不写，MyISAM 的 CONCURRENT INSERT 在有 DELETE 时也会退化为表锁；而 InnoDB 的读不加锁（RC/RR 隔离级下），天然适合读多写少场景——这点常被误认为“InnoDB 更慢”。
