最可靠的方式是运行 select @@default_storage_engine; 查看实际生效值，因该变量可能被动态修改或配置未加载成功，需同时检查全局、会话级变量及配置文件路径与语法。
如何确认当前 MySQL 默认存储引擎
MySQL 启动时会读取 default_storage_engine 配置项来决定新建表的默认引擎。但这个值可能被多处覆盖，不能只看配置文件。最可靠的方式是运行 SQL 查看实际生效值：
SELECT @@default_storage_engine;
常见错误现象：改了 my.cnf 却没生效，或者 CREATE TABLE 仍创建出 MyISAM 表——大概率是该变量被动态修改过，或配置未加载成功。
- 检查是否被运行时 SET 修改：
SELECT @@global.default_storage_engine;（全局）和SELECT @@session.default_storage_engine;（会话级，通常不生效） - 确认配置文件路径是否正确：用
mysqld --help --verbose | grep "Default options"查找实际加载的.cnf文件 - 注意：5.7+ 版本中，
default_storage_engine是动态变量，可运行时 SET，但重启后失效；而default_tmp_storage_engine不支持动态修改
在 my.cnf 中设置 default_storage_engine 的正确写法
必须放在 [mysqld] 段落下，不能写在 [client] 或全局段。常见错误是加了引号、用了等号右边带空格、或拼错变量名。
[mysqld] default_storage_engine = InnoDB
- 值必须是已安装且启用的引擎名，大小写不敏感，但建议全大写（如
InnoDB，不是innodb或INNODB） - 不要加引号：
default_storage_engine = "InnoDB"会导致启动失败，报错Unknown suffix 'InnoDB"' for variable 'default_storage_engine' - 若使用 MySQL 8.0+，
InnoDB已是硬编码默认值，但显式配置仍有必要，避免未来降级或特殊部署场景下行为漂移
为什么 CREATE TABLE 不按 default_storage_engine 走
即使 @@default_storage_engine 返回 InnoDB，新建表仍可能是 MyISAM，原因往往不在配置本身。
- 显式指定了 ENGINE：
CREATE TABLE t (id INT) ENGINE=MyISAM;—— 这会完全忽略默认值 - 使用了旧版建表语句（尤其从 dump 导入）：某些 mysqldump 输出会带
ENGINE=MyISAM，即使源库默认是 InnoDB - 表空间限制：如果
innodb_file_per_table=OFF且系统表空间满，InnoDB 可能静默退化为 MyISAM（极少见，但有日志佐证） - 权限问题：用户无权创建 InnoDB 表（如被显式
REVOKE CREATE TABLE），MySQL 可能 fallback 到 MyISAM（取决于版本和 sql_mode）
InnoDB vs MyISAM 对 default_storage_engine 的实际影响
选错默认引擎不只是“习惯问题”，它直接影响事务、崩溃恢复、并发能力。
-
InnoDB支持行锁、外键、ACID，但建表略慢、占用更多内存；若误设为MyISAM，所有新表自动失去事务能力，线上业务可能出数据不一致 -
MyISAM表级锁、不支持事务，但全文索引在老版本中更成熟；若仅用于只读报表库，设为 MyISAM 可省点开销，但 8.0+ 全文索引已在 InnoDB 完整支持 - 兼容性注意：MySQL 8.0.29+ 已废弃
MyISAM的某些特性（如修复表时的REPAIR TABLE语法变更），继续用默认 MyISAM 会增加升级成本
配置这事，真正麻烦的不是写哪一行，而是得同时盯住配置文件、启动日志、运行时变量、SQL 语句本身——漏掉任意一环，default_storage_engine 就只是个看起来很美的参数。
