php 不实现 btree 索引，由数据库引擎（如 innodb、postgresql）实现；btree 因减少磁盘 i/o、支持范围查询、保持有序插入性能而成为默认索引结构；innodb 实际使用 b+tree，主键索引聚簇存储，二级索引需回表；php 中不当写法（如索引列用函数）会导致索引失效。
PHP 本身不实现 BTree 索引，真正负责 BTree 索引的是底层数据库（如 MySQL 的 InnoDB、PostgreSQL），PHP 只是通过驱动（如 PDO、mysqli）发送 SQL 请求并接收结果。理解 BTree 索引的关键，在于看清数据库引擎如何组织和查找数据，而非 PHP 代码本身。
为什么 BTree 是关系型数据库的默认索引结构
BTree（Balance Tree）是一种自平衡的多路搜索树，专为磁盘 I/O 优化设计。相比二叉搜索树或哈希表，它有三个核心优势：
- 减少磁盘读取次数 ：每个节点可存储多个键值对（例如 100+），树高度通常仅 3–4 层，一次查询最多 3–4 次磁盘寻道即可定位记录；
- 支持范围查询 ：叶子节点按顺序链接，
WHERE age BETWEEN 25 AND 35或ORDER BY created_at LIMIT 10可高效扫描连续物理块； - 保持有序插入性能 ：分裂 / 合并机制保证树始终平衡，避免退化成链表，增删改查时间复杂度稳定在 O(logₙ m)（n 为阶数，m 为总记录数）。
InnoDB 中 BTree 索引的真实形态
InnoDB 的主键索引（Clustered Index）是典型的 B+Tree（BTree 的变种），其关键特征包括：
- 非叶子节点只存键 + 指针 ：不保存行数据，仅用于导航；
- 叶子节点存完整记录（主键索引）或主键值（二级索引）：主键索引的叶子页直接包含所有字段（聚簇存储），二级索引叶子页只存索引列 + 对应主键值，查数据需回表；
- 叶子节点双向链表连接 ：支撑高效范围扫描与排序；
- 页大小默认 16KB：每页容纳数百个索引项，实际树高极低——千万级数据通常仅 3 层。
例如执行 SELECT * FROM users WHERE email = 'a@b.com'，若 email 有唯一索引，InnoDB 会从根页开始逐层比对，3 次页加载即定位到叶子页中的具体记录。
PHP 开发中影响 BTree 效率的关键行为
PHP 层虽不建索引，但写法直接影响数据库能否命中 BTree 索引：
- 避免在索引列上使用函数或表达式 ：如
WHERE YEAR(created_at) = 2024无法走索引，应改用created_at >= '2024-01-01' AND created_at； - 前缀匹配慎用通配符开头 ：
LIKE '%abc'必然全表扫描，LIKE 'abc%'可用索引； - 联合索引注意最左前缀原则 ：索引
(a, b, c)能加速WHERE a=1、WHERE a=1 AND b=2，但WHERE b=2无效； - 避免隐式类型转换 ：字符串索引列传整型参数（如
WHERE status = 1，而 status 是 VARCHAR），可能触发全表扫描。
验证索引是否生效：从 PHP 到 EXPLAIN
不要凭感觉判断索引是否起作用。在 PHP 中调试时，应结合数据库原生命令：
- 用
PDO::exec("EXPLAIN SELECT ……")或mysqli_query($conn, "EXPLAIN SELECT ……")获取执行计划； - 重点关注
type字段：const/ref/range表示走了索引，ALL表示全表扫描； - 观察
key字段是否显示实际使用的索引名，rows是否显著小于表总行数； - 对慢查询，开启 MySQL 的
slow_query_log并用pt-query-digest分析真实瓶颈。
记住：PHP 的职责是发对 SQL，数据库的职责是用好 BTree。索引设计和 SQL 写法，才是决定性能上限的关键。
