InnoDB页大小初始化后不可动态修改，必须在实例创建时通过--innodb-page-size指定，重启或配置变更均无效，否则启动报错“page size mismatch”。
innodb_page_size 设置后不能动态修改
MySQL 的 innodb_page_size 是 InnoDB 存储引擎最底层的页单位，它决定了数据页、索引页、undo 页等所有物理存储块的大小。这个值在初始化实例时就固定了，后续无法通过 SET GLOBAL 或配置文件热生效——哪怕只是改个配置再重启，也会导致 MySQL 拒绝启动，报错类似：InnoDB: Error: page size mismatch。
常见错误现象：有人以为像 innodb_buffer_pool_size 那样改完配置重启就行，结果 mysqld 启动失败，error log 里反复出现页校验失败或无法识别系统表空间。
- 初始化时必须用
--innodb-page-size=4k|8k|16k|32k|64k参数（仅限 5.7+，且 32k/64k 需编译支持） - 默认是
16k，绝大多数线上环境不该改；除非你有大量超小记录（如 IoT 传感器单条几十字节）且内存极度受限，才可能考虑4k -
32k和64k会显著增加 B+ 树单层扇出，但会放大写放大和页分裂碎片，且备份工具（如 xtrabackup）、主从复制协议对大页支持不一
索引页大小 ≠ 索引字段长度限制
很多人混淆 innodb_page_size 和单个索引列能建多长——后者由 innodb_large_prefix 和 ROW_FORMAT 决定，跟页大小无直接关系。真正受页大小影响的是「一个页最多存多少索引项」以及「B+ 树每层能覆盖多少数据」。
举个例子：假设主键是 BIGINT（8 字节），非叶子节点只存主键+指针，16k 页大概能塞 1000+ 个键值；换成 4k 页就只剩约 250 个。这意味着同样数据量下，4k 页的 B+ 树会更深，一次主键查询平均多 1–2 次磁盘随机 I/O。
- 页越小 → 单页缓存利用率越低（更多页头/页尾元数据开销）
- 页越大 → 单次读取带宽更高，但容易造成“读多写少”：比如更新一行，却要重写整个
64k页 - SSD 随机读延迟低，所以
16k在多数 OLTP 场景仍是平衡点；HDD 环境下更不宜调小页
show engine innodb status 不显示实际页大小
执行 SHOW ENGINE INNODB STATUS\G 看到的 PAGE SIZE 字段，其实是编译时硬编码的默认值（通常是 16384），不是运行时真实页大小。它不会随初始化参数变化而更新，也不能用来验证当前实例是否真用了 4k 页。
正确确认方式只有两个：
- 查 error log 初始化阶段输出：搜索
InnoDB: Using page size of - 看系统表空间文件头：
hexdump -C ibdata1 | head -20，第 16 字节起的 4 字节是实际页大小（小端序）
别信 information_schema.INNODB_SYS_TABLESPACES 里的 FILE_SIZE 或 ALLOCATED_SIZE，它们只反映文件尺寸，不体现页粒度。
压缩表（ROW_FORMAT=COMPRESSED）绕不开页大小约束
启用 ROW_FORMAT=COMPRESSED 时，InnoDB 会在页级做 zlib 压缩，但压缩后的页仍必须对齐到 innodb_page_size。也就是说，即使压缩后实际内容只有 2KB，它依然占满一个 16k 页（剩余空间填零）。这会导致缓冲池浪费，尤其当行很稀疏或压缩率波动大时。
- 压缩页大小由
KEY_BLOCK_SIZE指定（如KEY_BLOCK_SIZE=8表示目标压缩页为 8KB），但它必须是innodb_page_size的约数 - 若设了
innodb_page_size=4k，那KEY_BLOCK_SIZE只能是1k或2k，不能设4k（等于没压） - 压缩表的二级索引页也受同样约束，且
COMPRESSED格式不支持全文索引、虚拟列索引等特性
真正影响读性能的，往往不是页大小本身，而是它和数据分布、访问模式、硬件 I/O 特性之间的耦合。调小页不等于更快，调大页也不等于更稳——边界条件比直觉复杂得多。
