1. B树索引在MySQL中的实战要点
1.1 B树索引的原理与数据结构
在MySQL的磁盘存储中，B树与B+树是实现高效索引的核心数据结构。
B+树的叶子节点保存键值的有序集合，并通过指针连接，提升前后游标的遍历速度，尤其适合范围查询和排序。有序性使得范围查询、排序优化器更加高效。
与传统平衡树不同，B+树的内部节点只作导航，不承载数据，最终的真实数据都集中在叶子节点，这一点对磁盘 IO 的效率有显著影响。磁盘块的缓存友好性是它在大规模数据中的关键优势。
1.2 B树在InnoDB中的实现要点
在InnoDB中，聚簇索引(CI)把表数据的行数据与主键值绑定在一起，叶子节点即是数据页，因此主键决定了聚簇索引的有序结构。非主键的二级索引则以主键作为指针，帮助回表，覆盖性不足时需要回表查询。
对一组二级索引进行设计时，最左前缀原则与多列顺序推荐遵循查询最频繁的前缀列，以确保索引的查找路径尽量短，减少随机 IO。
1.3 实战要点：覆盖索引与多列组合索引
覆盖索引是指查询所需字段全部被索引覆盖，避免回表 비용，在联合查询中尤其有效。为实现覆盖，通常需要把常用的查询列一起纳入一个联合B树索引。
下面的示例展示了一个典型的联合B树索引，用于常见的范围查询和排序场景：ORDER BY 与 WHERE 同时作用在(a, b)上的查询，能充分利用最左前缀。
CREATE TABLE orders (
order_id INT PRIMARY KEY,
customer_id INT,
order_date DATE,
amount DECIMAL(10,2),
INDEX idx_ab (customer_id, order_date) USING BTREE
) ENGINE=InnoDB;在执行计划阶段，利用 EXPLAIN 来评估是否走索引，查询性能 的改进往往来自于合理的字段顺序和覆盖性。
2. 哈希索引在MySQL中的实战要点与场景
2.1 哈希索引的原理与优缺点
哈希索引通过将关键字映射到哈希表的桶中，平均查找时间接近常数时间，极大提升等值查询性能。但不支持范围查询和排序，并且哈希冲突需要额外处理。
由于哈希索引的节省与速度优势，适合短期缓存与高频等值查询，但对长期数据的稳定性和持久性要求较高时应谨慎使用。
2.2 内存引擎MEMORY中的哈希索引使用方法
MySQL 的 MEMORY 引擎将数据存放在内存中，默认的索引类型是 BTREE，但可通过 USING HASH 指定哈希索引，以获得更快的等值查找。
需要注意的是，MEMORY 引擎是易失性的，断电或重启会清空数据，因此哈希索引更适合临时缓存或会话数据等场景。
CREATE TABLE caches (
id INT AUTO_INCREMENT PRIMARY KEY,
key_name VARCHAR(64),
value VARCHAR(255),
INDEX idx_key (key_name) USING HASH
) ENGINE=MEMORY;在查询阶段，如仅存在等值条件，哈希索引可以极大缩短查找路径；但若存在 范围条件，则应考虑切换到 BTREE 索引或结合两种索引策略。
2.3 哈希索引的局限性与成本分析
哈希索引的最大局限在于，无法直接用于 ORDER BY、不能支持范围查询，这会限制一些 analytial 查询的可用性。额外的存储开销与哈希冲突解决策略也需要考虑。
在进行容量规划时，内存使用、哈希桶数量与再哈希成本都应被纳入评估，避免在大数据场景下产生明显的冲突与缓存抖动。
3. 场景分析：如何在实际业务中选择与组合
3.1 按查询类型的场景分解
如果业务以等值查询为主，且数据集较小或使用内存表，哈希索引更具吸引力，能在极短时间内定位到结果。对于涉及范围查询、排序或分组的场景，B树索引仍是主力。
结合多列条件时，应采用联合B树索引，以实现前缀匹配和覆盖，实现高效的范围定位与排序。
3.2 按数据规模、持久性与容错分析
对大规模、持久化的业务表，磁盘上的B树索引（BTREE）是默认选择，原因是其稳定性与可持久性。对于临时数据和缓存数据，MEMORY+HASH 的组合可以提升局部查询的响应，但要权衡掉线后的数据丢失风险。
在实际应用中，通常需要两类索引协同工作：B树索引负责范围筛选和排序，哈希索引负责快速等值定位（若数据存放在内存表中），结合使用可以获得更平衡的查询性能。
如下示例展示了一个场景化的查询计划：EXPLAIN 与条件组合用于评估索引选择与执行路径：
EXPLAIN SELECT * FROM orders
WHERE customer_id = 123 AND order_date >= '2024-01-01'
ORDER BY order_date DESC LIMIT 10;