我之前也踩过完全一样的MySQL坑！连接时的socket错误、启动时的PID文件更新失败，其实都是InnoDB日志文件损坏引发的连锁反应。结合我当时的排查修复经验，给你一步步来解决：

第一步：紧急恢复InnoDB，先保住数据 #

InnoDB校验和失败（Log block has valid header, but checksum field contains X, should be Z）说明日志块的校验值不匹配，大概率是异常关机、磁盘波动导致的日志损坏。先尝试用紧急恢复模式启动：

• 先彻底停掉所有MySQL进程，避免二次损坏：

  sudo killall mysqld
  

• 编辑MySQL配置文件（常见路径是/etc/my.cnf或/etc/mysql/my.cnf），在[mysqld]区块添加紧急恢复参数：

  innodb_force_recovery = 1
  

  这个参数有1-6六个级别，1是最温和的（只跳过损坏的页），如果启动失败，再依次尝试2、3级别（级别4及以上可能会丢失数据，尽量不用）。
• 尝试启动MySQL：

  mysql.server start
  

• 一旦启动成功，立刻全量备份所有数据库，这步绝对不能省：

  mysqldump --all-databases > full_mysql_backup.sql
  

第二步：重建InnoDB日志文件 #

备份完成后，我们需要重建损坏的日志文件：

• 再次停止MySQL服务：

  mysql.server stop
  

• 回到配置文件，注释掉之前加的innodb_force_recovery，然后添加干净关闭参数：

  # innodb_force_recovery = 1
  innodb_fast_shutdown = 0
  

• 删除现有的InnoDB日志文件（通常在MySQL数据目录下，文件名是ib_logfile0、ib_logfile1）：

  # 替换成你的实际数据目录，比如/var/lib/mysql/
  sudo rm /var/lib/mysql/ib_logfile*
  

• 重新启动MySQL，此时InnoDB会自动生成全新的日志文件：

  mysql.server start
  

第三步：解决Socket和PID文件遗留问题 #

如果完成上面两步后，还是出现socket连接失败或PID文件报错，按以下步骤排查：

• 检查配置文件里的socket和pid-file路径是否正确，比如：

  socket = /tmp/mysql.sock
  pid-file = /var/run/mysqld/mysqld.pid
  

• 确保这些路径的目录存在，且MySQL用户有读写权限：

  sudo mkdir -p /var/run/mysqld
  sudo chown mysql:mysql /var/run/mysqld
  

• 临时应急的话，可以跳过socket连接，直接用TCP方式连接MySQL：

  mysql -h 127.0.0.1 -u root -p
  

额外注意事项 #

• 如果innodb_force_recovery到3级别都启动不了，大概率是磁盘物理损坏，建议用smartctl工具检查磁盘健康状态，云服务器的话联系服务商排查存储问题。
• 如果是迁移数据库后出现的问题，要确保新旧服务器的innodb_checksum_algorithm配置一致（比如都是crc32或innodb）。

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