MySQL索引页16KB是InnoDB硬编码物理边界，决定单页容量、溢出页触发及页分裂频率；大字段超限后移入独立溢出页，导致额外随机I/O、Buffer Pool命中率下降，且溢出页不参与索引查找、不被Data_free统计、释放依赖Purge线程。
MySQL索引页的16KB限制不是配置项，而是InnoDB存储引擎硬编码的物理边界——它直接决定单条记录能否存入一个页、是否触发溢出页、以及页分裂频率。这个限制不因字段类型或长度而改变，但会显著放大VARCHAR、TEXT、BLOB等大字段带来的性能代价。
为什么16KB页会导致溢出页（Off-page）？
InnoDB对大字段的处理取决于行格式：COMPACT和REDUNDANT会在主数据页中保留前768字节+20字节溢出指针；而DYNAMIC和COMPRESSED（推荐）只存20字节指针，其余全部移入独立溢出页。一旦字段内容超过页内预留空间，就必须走溢出路径。
- 溢出页本身不参与B+树索引查找，仅在回表时按指针加载——这意味着
SELECT *或覆盖索引失效场景下，每次查询都多一次随机I/O - 溢出页物理上不与主数据页连续，Buffer Pool命中率下降更明显
-
SHOW TABLE STATUS中的Data_free不统计溢出页碎片，容易误判“碎片不高”
大字段索引如何被16KB限制反向拖累？
给大字符串字段建普通索引（比如VARCHAR(2000)）时，InnoDB必须把完整值塞进索引页。即使只存前缀（如INDEX idx_name (name(100))），该前缀仍需满足单页容纳能力。一旦索引键过长，会导致：
- 单个索引页能存的键值数量锐减，B+树层级变深，
EXPLAIN中rows估算失真更严重 - 插入/更新时更容易触发页分裂——因为页填充率快速达到93.75%阈值（默认
innodb_fill_factor） -
ORDER BY无法使用前缀索引，强制走文件排序（Using filesort），且无法利用覆盖索引 - 二级索引叶子节点存的是主键值，若主键是
UUID，则每个索引页还要额外承载40+字节无序ID，进一步加剧分裂
真正有效的优化动作有哪些？
不要试图绕过16KB限制（它不可改），而是控制数据进入页的方式和密度：
- 将表行格式显式设为
DYNAMIC：ALTER TABLE t1 ROW_FORMAT=DYNAMIC;，避免COMPACT下768字节截断导致的隐式比较错误 - 大字段绝不参与联合索引的左侧列，尤其避免
WHERE a = ? AND b LIKE ?中b是TEXT——这种查询必然全表扫描 - 用
ANALYZE TABLE t1;更新统计信息后，再检查information_schema.INNODB_SYS_INDEXES中avg_data_length和n_leaf_pages，确认索引页平均利用率是否低于60% - 对已存在大量溢出页的表，
OPTIMIZE TABLE或ALTER TABLE t1 REBUILD;（MySQL 8.0.23+）可重排主数据页，但**不会合并或清理溢出页**——溢出页只能靠Purge线程异步回收，且不归还OS磁盘空间
最常被忽略的一点：溢出页的生命周期独立于主数据页，即使你DELETE了带大字段的记录，溢出页也不会立即释放；只有当对应记录被Purge线程彻底清除、且所在区段（extent）完全空闲时，才可能被标记为可复用。这意味着监控Data_free或innodb_page_size本身，根本看不到溢出页的真实开销。
