B+树节点大小等于16KB是因为InnoDB默认页大小为16KB，节点被设计为恰好填满一个数据页，使每次磁盘I/O都能加载完整节点，最大化IO效率；非叶子节点仅存键值和指针，叶子节点有序串联并支持范围查询，主键索引叶子存整行数据，二级索引叶子存索引列加主键值。
为什么B+树节点大小通常等于16KB
因为InnoDB默认页大小是16KB，B+树每个节点被设计为恰好填满一个数据页。这样每次磁盘I/O都能加载完整节点，避免多次读取——不是为了“凑整”，而是直接对齐硬件最小读写单元。
常见错误是误以为可以手动调小节点容量来“节省空间”。实际上innodb_page_size是编译时固定值，运行时不可更改；强行压缩键值会导致分支因子下降、树高上升，反而增加I/O次数。
- 主键索引的叶子节点存的是整行数据（聚簇索引）
- 二级索引叶子节点只存
索引列 + 主键值，不存其他字段 - 非叶子节点只存键值和子节点指针，不存任何真实数据
WHERE id BETWEEN 10 AND 100 怎么走索引
这是B+树最擅长的场景：先通过二分查找定位到id=10所在叶子节点，然后顺着叶子节点之间的双向链表往后遍历，直到id>100为止。
注意不是“从根往下找两次”，也不是“分别找起点和终点再合并”。整个过程只访问一次根→内部节点→叶子起始点，之后纯链表顺序扫描——所以范围越宽，I/O优势越明显。
- 如果
id是主键，链表里每个节点就是一行完整记录 - 如果
id是二级索引，链表里只有id和主键，查数据还得回表 - 若范围跨多个数据页，预读机制会提前加载后续页，进一步减少等待
插入新行时B+树怎么保持平衡
不是每次插入都触发分裂。只有当前叶子节点已满（比如16KB页里塞不下新键值对），才会拆成两个节点，并把中间键值提到父节点。父节点满了再向上递归，直到根节点——此时树高+1。
容易忽略的是：分裂不是均匀切分。InnoDB倾向于让新节点略空（预留约1/16空间），避免连续插入导致频繁重分裂。这也是为什么刚建完索引后大量INSERT比边建边插更快。
- 删除操作同理：合并发生在兄弟节点利用率低于50%时
-
OPTIMIZE TABLE本质是重建B+树，消除碎片但会锁表 - 自增主键天然有序，插入几乎不引发页分裂；随机UUID则极易造成页分裂和空间浪费
EXPLAIN看到type=range就一定用上索引了吗
不一定。type=range只说明走了索引的范围扫描，但可能只用到了索引的最左前缀，也可能因隐式类型转换或函数包裹导致实际未命中叶子节点。
比如WHERE create_time > '2025-01-01'用了索引，但WHERE DATE(create_time) > '2025-01-01'会让create_time索引失效——因为函数计算发生在引擎层，B+树无法直接比较处理后的值。
- 用
SHOW INDEX FROM table_name确认索引字段顺序和可使用性 -
key_len字段能反映实际用了几个索引列，比key更可信 - 覆盖索引（Extra里出现
Using index）意味着根本不用回表，性能差异巨大
COUNT(*)在无WHERE时可能直接走表扫描，哪怕有索引。这类行为依赖统计信息准确性，而ANALYZE TABLE不是定时自动执行的。 
