MySQL存储引擎不匹配导致ERROR 1033/1286，主因是my.cnf禁用引擎或配置异常；InnoDB锁退化与长事务引发性能雪崩；MyISAM易损坏需停服修复；ROW_FORMAT选错会导致I/O激增与空间浪费。
MySQL 存储引擎不匹配导致的 ERROR 1033 / ERROR 1286
当你执行 CREATE TABLE 或 ALTER TABLE 时遇到 ERROR 1033: Incorrect information in file，或查询时报 ERROR 1286: Unknown storage engine 'innodb'，基本可以断定是存储引擎未启用或配置异常。
常见原因不是语法写错，而是 my.cnf 中禁用了引擎，或 d 启动时跳过了关键模块。比如在较老版本 MySQL（5.5 之前）中，skip-innodb 仍默认存在；而 MySQL 8.0+ 已彻底移除 MyISAM 的全文索引兼容层，若应用还依赖 FULLTEXT + MyISAM，就会触发 ERROR 1286。
- 检查当前可用引擎：
SHOW ENGINES;
，确认
InnoDB的SUPPORT列为DEFAULT或YES - 若显示
DISABLED，查my.cnf是否含skip-innodb、disabled_storage_engines = "innodb"等配置 - MySQL 8.0.13+ 引入
disabled_storage_engines全局变量，默认值为"MyISAM,MRG_MYISAM,PERFORMANCE_SCHEMA"—— 注意它会阻止CREATE TABLE ... ENGINE=MyISAM，但不会影响已有表
InnoDB 表锁升级与长事务引发的性能雪崩
InnoDB 虽以行级锁著称，但一旦出现全表扫描、缺失索引、或显式加锁（如 SELECT ... FOR UPDATE 无 WHERE 条件），就会退化为表级锁。更隐蔽的问题是长事务：一个未提交的事务持续持有间隙锁（gap lock）或 next-key lock，会导致后续 DML 阻塞，甚至让 SHOW PROCESSLIST 中大量线程卡在 update 或 Waiting for table metadata lock 状态。
- 用
SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED;
查看运行超 60 秒的事务
- 结合
SELECT * FROM information_schema.INNODB_LOCK_WAITS;
定位被阻塞的 SQL 和源头事务 ID
- 避免在应用层手动开启事务后忘记
COMMIT或ROLLBACK；PHP 的PDO::ATTR_AUTOCOMMIT => true必须显式设置，否则默认 false - 批量更新务必分页，例如用
WHERE id BETWEEN ? AND ?替代WHERE status = 0全扫
MyISAM 表损坏与修复失败的典型路径
MyISAM 因崩溃后无法保证 ACID，极易出现 Client does not support authentication protocol（误报）、Table is marked as crashed 或 Incorrect key file for table。这类错误往往不是磁盘坏道，而是 mysqld 非正常退出（kill -9、OOM killer 干掉进程）导致 .MYI 索引文件与 .MYD 数据文件不同步。
本书将PHP开发与MySQL应用相结合，分别对PHP和MySQL做了深入浅出的分析，不仅介绍PHP和MySQL的一般概念，而且对PHP和MySQL的Web应用做了较全面的阐述，并包括几个经典且实用的例子。 本书是第4版，经过了全面的更新、重写和扩展，包括PHP5.3最新改进的特性（例如，更好的错误和异常处理），MySQL的存储过程和存储引擎，Ajax技术与Web2.0以及Web应用需要注意的安全
- 先尝试安全修复：
REPAIR TABLE tbl_name USE_FRM;
—— 仅当
.frm文件完好时才有效 - 若报
Can't repair with mrr, use extended repair，说明索引已严重错位，需停服后用命令行：myisamchk -r -v /var/lib/mysql/db/tbl_name.MYI
- 注意：
myisamchk必须在 mysqld 停止状态下运行，否则可能写坏文件；且修复后要执行FLUSH TABLES;让 MySQL 重新加载元数据 - 线上环境应禁止使用 MyISAM，尤其涉及计数器、日志类高频写场景 —— 它的并发插入（concurrent insert）只在尾部追加时有效，一旦有 DELETE 就失效
ENGINE=InnoDB ROW_FORMAT 选错带来的空间与性能陷阱
ROW_FORMAT 不只是“压缩与否”的开关。MySQL 5.7 默认 ROW_FORMAT=Dynamic，但若建表语句显式指定 ROW_FORMAT=Compact，且字段含大量 VARCHAR(2000)，就可能因行溢出（off-page）频繁触发二次 I/O，拖慢查询。更麻烦的是，ROW_FORMAT=Compressed 要求 KEY_BLOCK_SIZE 匹配 innodb_page_size（默认 16K），否则创建失败并报 ERROR 1005: Can't create table。
- 查看现有表格式：
SHOW CREATE TABLE tbl_name;
关注
ROW_FORMAT和KEY_BLOCK_SIZE -
Dynamic和Compressed支持大字段溢出到单独页，Compact和Redundant则强制将前 768 存主页，其余放溢出页 —— 这对SELECT *是隐形负担 - 压缩表必须满足：
innodb_file_per_table=ON、innodb_file_format=Barracuda（MySQL 5.7+ 已废弃该参数，但旧配置残留仍会干扰） - 别盲目开压缩：CPU 较弱的机器上，
ROW_FORMAT=Compressed KEY_BLOCK_SIZE=8可能降低 QPS 15% 以上，建议先在从库压测
实际调优时，最常被忽略的是存储引擎和行格式的组合效应 —— 比如把 InnoDB 表设为 ROW_FORMAT=Compact 又加了多个 TEXT 字段，表面看着没问题，但高并发下每行访问都要多一次磁盘寻道。这种问题不会立刻报错，只会让 P99 延迟悄悄爬升。
