InnoDB显示NO说明插件加载失败，主因是配置禁用（如skip-innodb）、ibdata1或ib_logfile不匹配、权限不足或路径错误，需查error.log定位首错并针对性清理文件或修正配置。
show engines 输出中 InnoDB 显示 NO
这是最直接的信号：InnoDB 插件没加载成功。别急着改配置，先确认当前 MySQL 实际加载了哪些引擎：SHOW ENGINES;。如果 InnoDB 对应的 Support 列是 NO，说明它被跳过或初始化失败。
常见原因有三类：
-
my.cnf或my.ini里存在skip-innodb或loose-skip-innodb—— 直接加#注释掉 -
default-storage-engine=MyISAM这类配置本身不导致 InnoDB 失效，但会掩盖问题；真正拦路的是禁用语句 - MySQL 启动时找不到
ibdata1或ib_logfile0，尤其在重装、迁移或磁盘异常后，日志里常出现InnoDB: The log sequence number in ibdata files does not match
error.log 里提示 InnoDB 初始化失败
错误日志才是真相来源。用 SHOW VARIABLES LIKE '%error%'; 查路径，然后打开对应文件（Linux 常在 /var/log/mysql/error.log，Windows 多在数据目录下 hostname.err）。重点搜这几行：
-
Plugin 'InnoDB' init function returned error→ 通常是ibdata1损坏或权限不对 -
Cannot open or create data files→innodb_data_home_dir或innodb_data_file_path配置错，或 MySQL 用户无写权限 -
Log file ./ib_logfile0 is of different size→ 日志文件大小和配置中innodb_log_file_size不匹配
注意：删 ib_logfile* 前必须先停服务，且最好备份；删完再启服务，MySQL 会自动重建（但 ibdata1 不能随便删，它含表结构和回滚段）。
MySQL 5.7+ 启动时卡在 InnoDB recovery
新版 MySQL 对 InnoDB 一致性更严格。如果上次异常关闭，启动时可能反复尝试恢复并报错退出，现象是服务起不来，日志里堆满 InnoDB: Starting crash recovery。这时候光改配置没用。
稳妥做法是：
- 确保
innodb_force_recovery没被设为非 0 值（除非你真在抢救数据） - 检查磁盘空间是否足够 ——
ibdata1扩展失败也会静默失败 - 若确定无重要数据，可停服务后删掉
ib_logfile0、ib_logfile1和ibdata1（仅限测试环境），再启动 - 生产环境优先从备份恢复，或用
mysqld --innodb-force-recovery=1尝试导出数据
PHPStudy / XAMPP 等集成环境中的典型陷阱
这类环境常预装精简版 MySQL，InnoDB 可能默认被裁掉。表现是 SHOW ENGINES; 根本不显示 InnoDB 行，而不仅是 NO。
解决路径很固定：
- 确认你编辑的是正在运行的实例所读的配置文件（PHPStudy 的
my.ini通常在D:\phpstudy_pro\Extensions\MySQL5.7.26\my.ini类似路径，不是控制面板里显示的那个“模板”） - 删
ib_logfile*前务必关掉所有 PHPStudy 相关进程（包括后台的mysqld.exe） - 加一行
innodb_flush_method = normal能绕过 Windows 下某些 I/O 权限问题，尤其在非管理员账户运行时 - 改完配置后，必须用控制面板「停止」再「启动」，而不是只点「重启」——后者有时不重载配置
InnoDB 不是开关式功能，它依赖一组文件、内存结构和初始化顺序。任何一环断开，Unknown storage engine 'InnoDB' 就不是配置改对就能立刻消失的错误。日志里的第一行报错，往往比 SHOW ENGINES 的结果更值得盯住。
