MySQL进程崩溃触发InnoDB断言错误buf0buf.h:1203，求助排查

核心问题定位 #

从错误日志可见，InnoDB在缓冲池获取页时触发断言m_space != nullptr，说明进程尝试访问一个不存在的表空间。大概率是表空间损坏、元数据异常，也可能是MySQL版本bug或硬件故障导致。

排查步骤 #

1. 检查表空间完整性 #

• 先以只读模式启动MySQL：在my.cnf中添加innodb_force_recovery=1，重启服务，避免进一步损坏数据。
• 执行命令检查所有InnoDB表：

CHECK TABLE your_table_name;

• 若发现损坏表，尝试用ALTER TABLE ... ENGINE=InnoDB重建；无法修复的话，直接从最近备份恢复。

2. 排查元数据异常 #

• 查询information_schema，确认表空间元数据是否正常：

SELECT * FROM information_schema.INNODB_TABLESPACES;
SELECT * FROM information_schema.INNODB_TABLES;

• 如果存在表空间文件（.ibd）但元数据无记录，或元数据有记录但文件缺失，需先备份数据再尝试修复元数据（操作风险高，谨慎执行）。

3. 验证硬件稳定性 #

• 检查磁盘健康：用smartctl查看磁盘SMART数据，排查坏道或IO错误：

smartctl -a /dev/your_disk_device

• 检测内存：运行memtest86+做全量内存测试，排除内存 corruption 问题。
• 查看宕机前后的系统监控（sar、iostat等），确认是否存在IO瓶颈或硬件负载异常。

4. 排查版本bug #

• 确认当前MySQL版本，若为8.0早期版本，建议直接升级到最新稳定版（如8.0.36及以上）——官方已修复大量InnoDB相关的断言失败bug。

5. 定位触发查询 #

• 查看慢查询日志或通用日志，找到宕机时间点前后执行的查询，重点关注涉及索引扫描、复杂关联的语句（堆栈显示宕机发生在ha_index_next_same执行阶段）。
• 拿到可疑查询后，在测试环境复现，确认是否会触发同样的断言失败。

临时缓解措施 #

• 若暂时无法彻底修复，可启用innodb_force_recovery=3（此模式下InnoDB只读，禁止写操作），先保证服务可用，同时尽快备份数据并推进根源排查。
• 暂停执行可疑查询，直到问题解决。

内容的提问来源于stack exchange，提问作者user15430325