索引通过B+树结构加速查询，主键索引存整行数据，二级索引需回表；高频WHERE、ORDER BY、JOIN字段及高基数列适合建索引；复合索引需遵循最左前缀原则并优先高区分度列；索引会降低写入性能并占用空间，应结合EXPLAIN和使用分析合理优化。
索引就像书的目录，没有它，查一个数据就得从头翻到尾（全表扫描）；有了它，数据库能直接跳到目标位置，大幅减少读取的数据页数量，查询自然就快了。
索引是怎么工作的？
数据库（如MySQL InnoDB）默认使用B+树组织索引。B+树所有数据都存在叶子节点，非叶子节点只存索引键和指针，结构扁平、层级少，查找通常只需2~4次磁盘I/O。主键索引（聚簇索引）的叶子节点存整行数据；普通索引（二级索引）叶子节点存主键值，查完还要回表一次——这是为什么“覆盖索引”能进一步提速的原因。
什么字段适合建索引？
不是所有字段都值得加索引。重点关注以下几类：
- WHERE条件中高频出现的列，尤其是等值（=）、范围（>、BETWEEN）、IN查询的字段
- ORDER BY 和 GROUP BY 后面的列，避免额外排序开销
- JOIN 关联字段（如 user_id、order_id），加速连接过程
- 基数高（取值分散）的字段更有效，比如手机号、邮箱；而性别、状态这类低基数字段效果有限，甚至可能被优化器忽略
怎么创建高效索引？
单列索引够用就别盲目上复合索引；真要用，注意最左前缀原则：
- 建立 (user_id, create_time, status) 复合索引后，能命中 user_id、(user_id, create_time)、(user_id, create_time, status) 这三种查询，但对 create_time 单独查询或 (status, user_id) 就无效
- 把区分度最高、过滤性最强的列放最左边
- 尽量让查询能“覆盖索引”：SELECT 的字段全部包含在索引中，就不需要回表。例如查 user_id 和 nickname，可建 (user_id, nickname) 索引
索引也有代价，别滥用
每次INSERT/UPDATE/DELETE都要更新索引树，写入变慢；索引本身占磁盘空间（尤其大文本或长字符串字段）；过多索引还会干扰优化器选错执行计划。建议：
- 上线前用 EXPLAIN 分析关键SQL，看是否走了预期索引、是否用了 filesort 或 temporary
- 定期检查 information_schema.STATISTICS 或使用 pt-index-usage 工具，清理长期未被使用的索引
- 对写多读少的表，谨慎添加索引；对日志类大表，可考虑分区 + 精准索引组合
基本上就这些。索引不是银弹，但理解原理后，加得准、用得好，一条慢查就能从几秒降到几十毫秒。
