MySQL 存储引擎不匹配导致的 ERROR 1033 / ERROR 1286
当你执行
CREATE TABLE或
ALTER TABLE时遇到
ERROR 1033: Incorrect information in file，或查询时报
ERROR 1286: Unknown storage engine 'innodb'，基本可以断定是存储引擎未启用或配置异常。
常见原因不是语法写错，而是
my.cnf中禁用了引擎，或 mysqld 启动时跳过了关键模块。比如在较老版本 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数据文件不同步。 先尝试安全修复：
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 延迟悄悄爬升。
