一个查询从毫秒变成几秒十有八九是索引出了问题。很多后端开发者习惯把性能瓶颈归咎于代码逻辑、缓存缺失或机器配置却忽略了最基础也最致命的一环——数据库索引。索引用对了查询效率提升百倍用错了不仅无效还会拖慢写入。这篇文章不谈玄学只讲实战中必须掌握的索引优化要点。索引的本质是空间换时间没有索引时数据库只能全表扫描逐行比对。数据量小的时候无所谓一旦表里几十万、上百万行全表扫描就是灾难。索引相当于书的目录通过预先排序的数据结构让数据库快速定位目标行。MySQL默认使用B树原因是它矮胖、磁盘IO少、范围查询友好。B树非叶子节点只存键值叶子节点存数据并形成链表所以既能快速等值查找也能高效范围扫描。聚簇索引与非聚簇索引的代价InnoDB的聚簇索引把数据行存在主键索引的叶子节点上也就是说表本身就是按主键组织的一棵B树。二级索引的叶子节点存的是主键值查二级索引拿到主键后再回聚簇索引取完整行这个过程叫“回表”。回表是性能杀手。如果查询只需要二级索引里已有的字段就不需要回表这就是覆盖索引。比如在user表上建了(name, age)联合索引查询select name, age from user where name 张三直接走索引就能拿到数据无需回表。联合索引与最左前缀原则联合索引(a, b, c)相当于按a排序a相同再按bb相同再按c。查询条件必须从最左列开始连续匹配否则索引失效。where a1 and b2能用where b2不能用where a1 and c3只能用到a列。范围查询会中断后续列的使用比如where a1 and b2 and c3c列用不上索引。设计联合索引时把等值查询的列放前面范围查询的列放后面这是基本口诀。索引失效的常见陷阱在索引列上做运算或函数操作比如where year(create_time)2024索引直接废掉应改成where create_time between 2024-01-01 and 2024-12-31。隐式类型转换同样致命字符串列用数字查询比如where phone13800000000如果phone是varcharMySQL会把列转成数字再比较索引失效。like %张前置通配符无法走索引like 张%可以。or连接非索引列、not in、!也容易导致全表扫描。用EXPLAIN看清真相别猜用EXPLAIN看执行计划。重点关注type列ALL是全表扫描index是全索引扫描range是范围扫描ref是非唯一索引查找eq_ref是唯一索引查找const是常量查找。目标是至少达到range最好ref以上。key列显示实际使用的索引rows列估算扫描行数Extra里出现Using filesort或Using temporary说明需要优化排序和分组。Using index表示覆盖索引是好信号。索引不是越多越好每个索引都要占用磁盘空间写入时还要维护B树降低插入、更新、删除的速度。一张表建五六个索引写入性能可能下降一半。原则是高频查询字段建索引区分度高的字段建索引联合索引能覆盖多个查询场景就不要再建单列索引。定期用SHOW INDEX和慢查询日志审查冗余索引把不用的删掉。索引优化是后端性能提升的第一课也是性价比最高的一课。不写代码不改架构只调整几个索引查询就能从秒级降到毫秒级。但索引不是银弹它需要你理解查询模式、数据分布和数据库原理。多写EXPLAIN多看慢日志少凭感觉建索引。性能优化没有捷径只有对细节的持续较真。