索引是减少磁盘 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 > '2024-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) = 2024→ 改成WHERE create_time >= '2024-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+ 树层级是硬约束，所有优化都绕不开这两点。
