索引字段越小，B+树非叶子节点每页可存键值越多，扇出越大，同等数据量下树高越低；如INT主键通常使千万级数据保持3层，而长字符串主键易致4层，增加I/O开销。
索引字段越小，B+Tree非叶子节点能存的键值越多
非叶子节点只存键值和指针，不存数据，但每个页（16KB）大小固定。字段越长（比如用 VARCHAR(255) 存邮箱），单个键值占用字节数就越多，一页能塞下的键值数量就越少；反之，用 INT 或 BIGINT 作主键，一个键通常只占 4~8 字节，一页轻松存几百个键。
键值密度直接决定树高：键越多 → 每层扇出（fan-out）越大 → 同等数据量下层级越少。实测中，1000 万行数据，用 INT 主键时 B+Tree 通常为 3 层；换成 VARCHAR(64) 且平均长度 40 字节后，同样数据量可能升到 4 层——多一次磁盘 I/O，查询延迟明显上升。
- 主键类型优先选
INT、BIGINT，避免VARCHAR、TEXT、UUID（除非业务强依赖） - 联合索引中，把区分度高且长度小的字段放在左边，比如
(status, user_id)比(user_id, status)更易触发最左前缀，也更省空间 -
innodb_page_size默认不可改，所以压缩键值是唯一可控手段；COMPRESS或前缀索引（name(10)）可临时缓解，但有语义截断风险
自增主键能减少页分裂，间接压低树高
B+Tree 插入新记录时，如果主键无序（如随机 UUID），新数据大概率落在中间某个已满的叶子页里，触发频繁的页分裂；每次分裂不仅产生新页，还可能向上级节点传播分裂压力，甚至最终导致根节点分裂、树高+1。
而自增主键保证插入总在右侧追加，叶子页基本顺序填满，分裂频次大幅降低。即使发生分裂，也多是“右倾”分裂（旧页留前半、新页接后半），对上层影响小。
- 不要用
UUID()或MD5()直接作主键，除非你明确接受写放大和潜在的树高增长 - 若必须用字符串 ID，考虑将其哈希后转为
BIGINT存为辅助列，并建索引，主键仍用自增 -
innodb_fill_factor设置过低（如 50）会人为预留空隙，反而增加页数和树高，生产环境建议保持默认 90 或 100
二级索引字段大，会导致回表开销翻倍
二级索引叶子节点只存索引列值 + 主键值。如果索引列本身很大（比如 email VARCHAR(255)），那每个叶子项体积膨胀，同样 16KB 页能存的索引项就变少 → 叶子页数量增多 → 扫描范围查询时要读更多页；更关键的是，主键值也会被重复存储在每个二级索引里，主键越长，这种冗余越严重。
例如：主键是 CHAR(36) 的 UUID，二级索引 (email) 的每个叶子节点既要存 email（平均 30 字节），又要存那个 36 字节 UUID，合计近 70 字节；而主键是 INT 时，同样索引每个叶子才约 34 字节 —— 空间差一倍，页数也差一倍。
- 避免在二级索引中包含大字段；必要时用覆盖索引，把常用查询字段全包含进去，避免回表
- 用
SHOW INDEX FROM table_name查看Sub_part列，确认是否用了前缀索引；前缀过短会降低区分度，过长又浪费空间 - 执行
SELECT COUNT(*) FROM information_schema.INNODB_SYS_INDEXES WHERE NAME = 'idx_name'可查索引页数，对比不同设计的实际占用
B+Tree 层级不是配置出来的，是数据写入过程中被页分裂“推高”的。字段大小影响的是每页容量，而每页容量决定了分裂频率和树高的增长速度——这点容易被忽略，因为日常 EXPLAIN 看不到树高，只有当慢查询突然变多、且 Handler_read_next 暴涨时，才可能意识到是索引结构悄悄变胖了。
