InnoDB页大小不匹配会导致MySQL启动失败，需通过SELECT @@innodb_page_size和hexdump检查配置与ibdata1/.ibd文件头偏移26–29字节（小端序）是否一致；该参数只读，不可运行时修改，修复只能重建实例并重新导入数据。
查 innodb_page_size 配置和实际数据文件页大小是否一致
MySQL 启动时报 InnoDB page size mismatch，本质是 InnoDB 试图读取一个数据页时，发现页头里记录的页大小（比如 16KB）和当前实例配置的 innodb_page_size（比如 4KB）对不上。这通常发生在迁移、恢复或误改配置后。
先确认当前 MySQL 实例的配置值：
SELECT @@innodb_page_size;
再检查 ibdata1 或独立表空间文件（如 test/t1.ibd）的真实页大小——最可靠的方式是用 hexdump 看前 4 字节（页头偏移 26–29）：
hexdump -C -n 32 /var/lib/mysql/ibdata1 | head -n 2
输出中第 27 字节（0x1a 偏移）起的 4 字节是页大小（小端序），比如 00 00 40 00 表示 16384（即 16KB）。
- 如果配置值和文件实际页大小不一致，
mysqld一定启动失败，不能硬改配置强启 -
innodb_page_size是只读变量，必须在初始化实例时指定，运行中不可修改 - 从 MySQL 5.7 开始，默认是 16KB；早期版本或自定义编译可能为 4KB/8KB/64KB
恢复时别直接拷 ibd 文件到不同页大小的实例
这是最常见的诱因：把一个 16KB 页的 t1.ibd 直接复制到 innodb_page_size=4K 的新实例里，然后执行 ALTER TABLE ... IMPORT TABLESPACE，必然报错。
真实场景中容易忽略的点：
- 备份恢复工具（如
mydumper+myloader）不校验页大小，只管 SQL 重放，但如果你混用了物理备份（cp ibd）和逻辑恢复，就埋了坑 -
mysqlbackup（MEB）或Percona XtraBackup会记录源实例的innodb_page_size到元数据，还原时校验失败会明确提示，比手动拷文件安全得多 - 即使表是
ROW_FORMAT=COMPACT或DYNAMIC，也改变不了底层页大小，它由 ibdata1 和每个 .ibd 文件自身决定
用 strings + grep 快速筛出损坏或混杂的表空间文件
当不确定哪些 .ibd 文件有问题，又不想逐个 hexdump，可以用字符串扫描辅助定位：
strings -n 4 /var/lib/mysql/test/t1.ibd | grep -E "^(16384|4096|8192|65536)$"
这个命令会提取所有长度 ≥4 的可打印字符串，再过滤出可能是页大小的数字。虽然不 100% 可靠（可能误匹配日志或注释），但能快速标出异常文件。
- 真正有效的页大小标记在文件开头固定位置，
strings只是辅助筛查，不能替代hexdump确认 - 如果输出里同时出现
16384和4096，说明该文件可能被截断、覆盖或跨版本写入过，基本不可用 - 空输出不一定代表正常——有些极小的表空间（如刚 CREATE 没 INSERT 的表）可能还没写满第一页，页头没刷盘
修复只能重建，没有“在线转换页大小”的方案
MySQL 官方不提供任何工具能把 4KB 的 ibd 文件转成 16KB，反之亦然。InnoDB 的页结构、校验逻辑、内存管理全绑死在编译/初始化时的 innodb_page_size 上。
可行路径只有两条：
- 导出数据（
mysqldump或SELECT ... INTO OUTFILE），停掉原实例，用正确页大小重新初始化新实例，再导入 - 用
xtrabackup --copy-back恢复时确保目标实例的my.cnf中innodb_page_size和备份时完全一致（查看xtrabackup_info文件里的innodb_page_size字段）
试图用 dd 修改 ibdata1 头部、或 patch mysqld 二进制绕过校验，会导致后续崩溃、数据错乱，别试。
页大小不匹配不是校验和错误那种“可能还能抢救”的问题，它是 InnoDB 初始化阶段就拒绝加载的硬性约束——文件和配置对不上，就是两个世界的东西。
