在日常开发中，SQL执行效率直接影响系统性能。作为Java后端工程师，掌握MySQL索引的原理与实践至关重要。下面通过几个常见场景梳理MySQL索引的核心要点。
首先，索引本质上是一种数据结构，MySQL InnoDB常用的是B+树。B+树只在叶子节点存储实际数据，并通过双向链表连接叶子节点，范围查询更加高效，且树高度更低，能减少磁盘I/O次数。B+树天然适合范围扫描与排序场景，这也是为什么它能成为默认索引结构的原因之一。
聚簇索引与辅助索引是InnoDB的两个重要概念。聚簇索引一般就是主键索引，叶子节点存储完整行数据，表数据文件本身就是主键索引文件。辅助索引的叶子节点存储主键值，通过辅助索引找到主键后再回到聚簇索引查找完整行，这个过程通常称为回表。如果查询的字段都在辅助索引上，就能避免回表，形成覆盖索引，是减少I/O的有效手段。
联合索引中常见的是"最左前缀"规则。对于联合索引（A,B,C），能够命中的条件包括：A、A,B、A,B,C，单独B或单独C无法利用该联合索引进行范围定位。编写SQL时要注意字段顺序与条件组合，尽量让查询条件符合索引的左匹配原则。同时，如果最左侧列等值匹配，后续列也可以参与索引匹配进行范围或排序。
索引下推是MySQL 5.6之后的重要优化，可以将索引中的字段条件在存储引擎层先过滤，减少返回Server层的记录数，提升效率。特别是在联合索引查询时，把能下推的条件尽量包含在索引中，能有效降低网络和内存开销。
索引失效的典型场景包括：对字段使用函数运算、隐式类型转换、前导模糊查询（like %x）、负向条件（!=、not in、not like）、or条件未全部命中索引等。这些都会导致MySQL无法使用索引树进行范围查找，转而进行全表扫描，影响性能。开发中应尽量避免这些写法，必要时可通过改写SQL或添加合适的索引解决。
在分页和深分页场景中，索引也能起到关键作用。利用覆盖索引先查出主键，再与原表Join获取完整数据，往往比直接limit offset,size性能更好。对于深分页，可以使用延迟关联或记录最大ID的方式优化，避免过多回表和扫描。
最后，索引不是越多越好。每个索引都会占用存储空间，并在写操作时带来维护成本。应根据业务查询频率与更新频率权衡，优先给高查询频率、高区分度、经常作为条件或排序的字段建立索引，对低区分度字段（如性别、状态）要谨慎处理。
感谢读者观看