innodb_page_size必须在初始化MySQL实例前设置，运行中不可修改；它决定单行数据页内存储上限，影响B-tree深度与IO性能，增大页大小可提升单行容量但牺牲压缩功能和兼容性。
不能在已有实例上修改 innodb_page_size，它必须在初始化 MySQL 实例前就确定。 试图在运行中的 MySQL 8.0 实例里动态调整或 ALTER SYSTEM 设置该参数，会直接失败——MySQL 启动时就将页大小硬编码进 ibdata1 和所有表空间元数据中，后续完全不可变更。
为什么 innodb_page_size 会影响单行数据容量
InnoDB 行数据物理上必须能放进一个页（page）内（不含溢出部分）。默认 innodb_page_size=16384（16KB），扣除页头、系统列、NULL 位图、变长字段列表和预留更新空间后，单行有效载荷上限约 7,950 字节。若你明确需要更大的「主键页内可容纳量」（比如避免大量小 VARCHAR 或 JSON 触发溢出），增大页大小是唯一底层路径：
- 设为
32K：单行主键页内上限升至 ≈ 16,000 字节 - 设为
64K：上限 ≈ 32,000 字节（但注意：此尺寸下不支持ROW_FORMAT=COMPRESSED） - 页越大，B-tree 索引层级越浅，范围扫描可能更快；但随机读的内存/IO 开销也同步放大
初始化新实例时设置 innodb_page_size 的实操要点
仅限全新部署，且需在 mysqld --initialize 前完成配置：
- 在
my.cnf的[mysqld]段落中添加：innodb_page_size=32768（单位字节，即 32K） - 确保
datadir目录为空，且未运行过任何 MySQL 进程 - 执行初始化：
mysqld --initialize --user=mysql（不要加--datadir参数覆盖配置） - 启动服务后，验证：
SELECT @@innodb_page_size;应返回32768 - 注意：Linux 文件系统块大小（
getconf PAGESIZE）最好与之对齐，否则可能引入额外读 IO
配置后必须面对的兼容性限制
增大页大小不是“开箱即用”的优化，而是一次架构级取舍：
-
ROW_FORMAT=COMPRESSED在32K或64K下被禁用，压缩功能彻底不可用 - 所有表空间（包括系统表空间
ibdata1、通用表空间、独立表空间）强制使用该页大小，无法混用 - 备份工具（如
mysqldump）不受影响，但物理备份（xtrabackup）必须用同页大小版本，跨页大小恢复会报错 -
innodb_log_write_ahead_size最大值被截断为innodb_page_size，若原设 16K 日志写入提前量，在 32K 实例中仍生效，但逻辑意义已不同
真正需要大页的场景极少——绝大多数业务靠 TEXT/JSON 溢出机制就能透明支撑 GB 级单字段，而页大小改动牵一发动全身。除非你正构建 OLAP 类宽表、且实测 16K 页导致严重溢出页随机 IO 成瓶颈，否则别碰它。
