索引是减少磁盘IO的物理手段，本质是排序的“小表”，存列值和数据行地址；B+树结构支持高效查找、范围查询与排序；需依执行计划评估，避免无效索引。

索引就是数据库的“目录”，不是加速查询的魔法，而是减少磁盘 IO 的物理手段

MySQL 索引本质是一张额外的、排序过的“小表”，里面存的是 列值 + 对应数据行的磁盘地址（或主键）。它不改变原表数据，但让查询不用扫全表——比如查 WHERE name = '张三'，有索引时，MySQL 直接在索引 B+ 树里二分查找，定位到叶子节点，再按地址取数据；没索引就得从第一页磁盘读到最后一行，IO 次数可能差几十倍。

• B+ 树是 InnoDB 默认且最常用的数据结构：非叶子节点只存键和指针，叶子节点存完整数据（聚簇索引）或主键（二级索引），且叶子间用双向链表连起来，天然支持范围查询（BETWEEN、>=）和排序（ORDER BY）
• 索引不是越多越好：每个索引都要占磁盘空间，写操作（INSERT/UPDATE/DELETE）时还要同步更新索引树，拖慢写入速度
• 重复值高的列（如 gender 只有 'M'/'F'）建索引效果极差，优化器很可能直接放弃使用

什么时候该建索引？看执行计划比凭感觉靠谱得多

别猜“这列经常 where 就该加索引”。先用 EXPLAIN 看 MySQL 实际怎么走的：

EXPLAIN SELECT * FROM users WHERE status = 1 AND created_at > '2025-01-01';

重点关注 type 字段：ALL 是全表扫描（危险），range 或 ref 才算走了索引；key 显示实际用的索引名；rows 是预估扫描行数——如果远大于结果集，说明索引效率低或没选对。

• 单列索引适合等值查询（=、IN）和高区分度字段（如 user_id）
• 联合索引要注意最左前缀原则：索引 (a, b, c) 能命中 WHERE a=1、WHERE a=1 AND b=2、WHERE a=1 AND b=2 AND c=3，但 WHERE b=2 或 WHERE a=1 AND c=3 无法利用后两列
• 覆盖索引能避免回表：如果 SELECT id, name FROM users WHERE name = '李四'，而索引是 (name, id)，那查完索引就拿到全部字段，不用再根据主键去聚簇索引捞数据

常见踩坑：这些“看起来合理”的索引其实无效

很多线上慢查询，根源不是没建索引，而是建了但白建了：

• 在 WHERE 条件里对索引列用了函数或表达式：WHERE YEAR(create_time) = 2025 → 改成 WHERE create_time >= '2025-01-01' AND create_time
• 隐式类型转换：user_id 是 INT，却写 WHERE user_id = '123' → 字符串强制转数字会丢索引
• 用 LIKE 以通配符开头：WHERE name LIKE '%辉' → B+ 树没法从头匹配，只能全扫；LIKE '张%' 才有效
• 索引列参与运算：WHERE score + 10 > 90 → 必须改写为 WHERE score > 80

建索引不是一劳永逸，得定期检查和清理

业务迭代后，旧索引可能长期未被使用，反而拖累写性能。InnoDB 提供了统计信息：

SELECT * FROM sys.schema_unused_indexes WHERE object_schema = 'your_db';

（需开启 performance_schema 并导入 sys 库）

• 高频更新但低频查询的列，谨慎加索引；可考虑延迟构建或用缓存替代
• 联合索引顺序要按查询频率和区分度综合排：高区分度、常用于等值过滤的放左边，范围查询（>、BETWEEN）的放右边
• 删除索引前务必确认：查 information_schema.STATISTICS 或用 pt-index-usage 工具分析历史慢日志

真正难的从来不是“怎么建索引”，而是判断“要不要建”以及“建了之后它到底有没有被用上”。磁盘 IO 和 B+ 树层级是硬约束，所有优化都绕不开这两点。