索引就是数据库的“目录”，不是加速查询的魔法，而是减少磁盘 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+ 树层级是硬约束，所有优化都绕不开这两点。
