必须显式写ENGINE=InnoDB，因默认引擎不可靠：配置在不同MySQL版本中差异大（5.6依赖default-storage-engine、5.7弃用该配置、8.0+只读），迁移或配置错误易致表误用MyISAM；验证须查SHOW CREATE TABLE或information_schema，而非仅信@@default_storage_engine。
CREATE TABLE 必须显式写 ENGINE=InnoDB
即使 MySQL 当前默认引擎是 InnoDB，也不代表建表一定用它——尤其当脚本迁移到其他实例、或配置被意外覆盖时，CREATE TABLE t (id INT) 可能落到 MyISAM 上。这不是 bug，而是 MySQL 的行为设计：默认值只在“未指定且无配置干扰”时生效，而配置本身又因版本差异极不可靠。
- MySQL 5.6 及以前：依赖
default-storage-engine配置，但常被忽略或配错段落 - MySQL 5.7：该配置已弃用，设了也无效，仅
default_storage_engine变量临时起作用 - MySQL 8.0+：
default_storage_engine是只读变量，SET GLOBAL直接报错Variable 'default_storage_engine' is a read only variable
所以唯一跨版本、跨环境可靠的方案，就是每条 CREATE TABLE 都带上 ENGINE=InnoDB。
验证表是否真用了 InnoDB，别信 @@default_storage_engine
SELECT @@default_storage_engine 返回 InnoDB ≠ 你刚建的表就是 InnoDB。常见坑是：配置改了但没重启 mysqld，或改错了配置文件路径（比如改了 /etc/my.cnf，实际加载的是 /etc/mysql/my.cnf），导致 mysqld --verbose --help | grep "default-storage-engine" 仍显示 MyISAM。
- 正确验证方式：执行
SHOW CREATE TABLE t\G，确认输出中明确含ENGINE=InnoDB - 批量检查：用
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db' - 如果发现某张表是
MyISAM，立刻用ALTER TABLE t ENGINE=InnoDB转换，别等外键或事务出问题
MySQL 8.0+ 不允许降级默认引擎，不是配置没生效，是根本堵死了
在 MySQL 8.0 中试图通过 default-storage-engine=MyISAM 或 SET GLOBAL default_storage_engine = 'MyISAM' 改回 MyISAM，会失败或被忽略。这不是权限或语法问题，而是架构限制：
- 系统表（如
mysql.user、mysql.roles_mapping）全部强制使用InnoDB，MyISAM 无法承载 ACL 和原子 DDL - 数据字典（Data Dictionary）本身基于
InnoDB实现，切换引擎会导致CREATE USER、GRANT等命令直接报错 - 启动参数
--default-storage-engine=MyISAM会触发错误：Unknown suffix 'MyISAM' for variable 'default-storage-engine'
换句话说：你不是没配对，是你想配的东西在 8.0+ 已经不存在了。
建表时顺便控制 InnoDB 行格式和表空间
显式写 ENGINE=InnoDB 只是起点。真正影响性能和运维的是后续细节：
- 行格式推荐用
ROW_FORMAT=DYNAMIC（MySQL 5.7+ 默认），避免TEXT/BLOB字段触发行溢出问题 - 启用
innodb_file_per_table=ON（默认开启），确保每张表有独立.ibd文件，方便TRUNCATE后释放磁盘空间 - 若需把表放进通用表空间，必须显式写
TABLESPACE ts_name，不能只靠引擎声明 - 不要依赖
innodb_default_row_format变量来统一控制——它只影响“未显式指定 ROW_FORMAT”的建表语句，而你已经决定显式写了ENGINE，顺手加上ROW_FORMAT更稳妥
最简可靠建表语句示例：
CREATE TABLE t (id BIGINT PRIMARY KEY, data JSON) ENGINE=InnoDB ROW_FORMAT=DYNAMIC;漏掉任何一项，都可能在某个版本或某次迁移中埋下隐患。
