在日常开发中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的方式优化避免过多回表和扫描。最后索引不是越多越好。每个索引都会占用存储空间并在写操作时带来维护成本。应根据业务查询频率与更新频率权衡优先给高查询频率、高区分度、经常作为条件或排序的字段建立索引对低区分度字段如性别、状态要谨慎处理。感谢读者观看